Can't load firmware on Huzzah's

[mcL]

Hello everyone! Sorry to ask so much on my first post (and at Christmas!) but here goes...

A little backstory
I am no expert but I've been working with microcontrollers off and on for few decades (starting with Motorola 6800's in machine a LONG time ago). I was having an intermittent over-temperature problem in my radiant heating system and decided to dust off a couple Adafruit Huzzah ESP8266 bds I had laying around and connect them to several DS18 temperature sensors to see what was going on. Of course I've been "adjusting" the program daily, but I had the webrepl interface working fine, rshell working fine, and the data was being collected fine. Also, just turned on MQTT and had the 4 sensors sending to my Android phone using my RPi (running PiHole) as the broker using mosquitto.

My main loop normally samples every 10 seconds and prints and writes the string to a file. A new file is created at noon everyday. I didn't (don't) have real-time plotting going yet so every morning I would download the previous day's log file manually (via webrepl or rshell) and delete the copy on the esp. I got busy and didn't remove the file for a couple days (and left a couple copies on chip) and then one day the esp just died. os.statvfs showed 0 free blocks so I filled up the available storage. I deleted all the log files, rebooted, and reloaded my script and all was well (I thought). OK, I'm not 100% sure of the sequence of events thereon, but basically:
. while I had it down I decided to upgrade to 1.12, mostly so I could take advantage of littlefs features. I first did a esptool erase_flash as recommended, but it failed. I also couldn't load 1.12. (errors below)
. I have tried everything I can think of: used different USB port on my Thinkpad, used a external powered USB hub, use a external bench PS @ 3.6v on the 3v pin of Huzzah, gnd gpio0 on/off during power cycle, tried multiple (known good) cables, tried slow baud rates. Nothing changes the failure mode.
. So now I load up my backup Huzzah (esp bd) it takes off and runs fine; however, during my MQTT testing I have the sample period turned down to 1 second and I forget to turn it back up to 10 sec for overnight. Now I can't sleep all night remembering what I did (of course, I don't get up and fix it) and that it going to run out of space 10x faster than before, which means it might not make it through the night. Well, in the morning it's still publishing MQTT data, BUT I can't webrepl in. I removed the unit and connect it to my laptop and I can't rshell in. So now I have no way to remove/cleanup the file system. My only choice is reload the firmware. When I tried to do so IT fails as well, failing to erase_flash or load the firmware, but in a different way than the other unit.

Conclusion...Uh,I don't know!
Is it possible that by trying to write to the filesystem when it now longer has space to write (of course, my app doesn't check for that!) somehow I killed both units so bad that esptool can no longer talk to it? The one unit either loads the firmware up to either 28 or 40% then hangs. Ctl-c does NOT breath life back into it; I have to always reset the USB cable.

I have another unit coming in today, but I would sure like to understand what's happening so I don't keep smoking these things! I guess I might have f'd up my USB ports, but I find that unlikely? I'll know when I try to load uP on my new unit tomorrow. Also have a Win7 box I could try esptool with... Is there a lower level way to breath life back into these?

Thank you for reading and hope everyone has a good Holiday!

Greg
using POP!_OS, Ubuntu, Lenovo Thinkpad (which successfully programmed the unit many times on both ports)

Sample output (each unit has a different failure mode, which is more crazy):
UNIT 7F
python -m esptool --port /dev/ttyUSB0 erase_flash
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting........_____....._____....._____....._____....._____....._____....._____
A fatal error occurred: Failed to connect to Espressif device: Timed out waiting for packet header

UNIT 96
python -m esptool --port /dev/ttyUSB0 erase_flash
esptool.py v2.8
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 5c:cf:7f:0e:36:96
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...

[jedie]

Just a small note: I wouldn't write the data to flash, because of limited life time.
Why not send it directly via MQTT? Maybe collect some data in RAM and send in a bulk.

[mcL]

Agreed! That was/is my plan, but I started out just writing to flash/filesystem during development. I'd plan to push the data to the RPi that's on the network already, but I haven't got that done yet. (Need to figure out HOW to do that). I should at least be checking for free space before writing...next rev.

[mcL]

Update:
I received a new Huzzah and it immediately was able to esptool erase_flash (took 7.9sec). I then loaded uP 1.12 no problem. After power cycling the esp seemed to be stuck in a bootloop: the blue led flickered continuously and connecting to the serial port via minicom showed a stream of chars (I understand the boot message is at a different baud, but I was connected at 115200 which should allow me to ctl-c into the >>> prompt). I was unable to ctl-c to get the REPL prompt. I did a 'verify_flash' and it checked ok. I loaded v1.11 (which I know works) and got the same boot loop. Tried a bunch of tricks from Adafruit support site with no success. Reloaded v1.12 but this time did NOT hit the reset button after the load, and now I was able to get into REPL and load my .py files, and run them.

I still can't breath life into my previous 2 units using all the tricks recommended at Adafruit. I guess the conclusion is that my computer USB ports and cables are fine and the 2 units must be dead. I noticed that one of the guys reporting the same issue, albeit in 2015, on the Adafruit support was also using MQTT. Is it remotely plausible that could somehow have killed these things? Death occurred shortly after implementing mqtt. (I think I may be using mqtt.connect() too many times -- something I need to look into.)

Searching "bricked huzzah" or "boot loop huzzah" produces many results throughout the years! I also noticed that the new Huzzah has a different layout for the antenna.

[Christian Walther]

boot loop

In my experience, this is a symptom of using the wrong flash mode. Try different values for the -fm argument of esptool.py.

(That doesn’t explain the inability to erase_flash though.)