Difficulty flashing ESP8266
Posted: Sat Mar 10, 2018 11:13 pmSo about 2 years ago I got 10 of these ESP8266 and never did anything with them: they have all sat in anti-static bags since around June of 2016. This weekend I found them, had some free time, and started messing around with them. 7 of them work exactly as expected with the (albeit very old) firmware and their respective AT commands, one of them is completely DOA, and the last two boot with "MEM CHECK ERROR" and frequently reset themselves when trying to do anything.
As a first test I intended to build a simple wifi repeater: found a guide, wired one up, downloaded the prebuilt firmware, attempted to flash... and failure after failure.
For background, these are all ESP8266-07 or -12 I think, with ceramic antennas and 4Mb of flash. I'm running Linux using esptool.py. Even basic commands, like read_mac and flash_id fail. Sometimes it'll just spin at "Connecting...." until it times out; sometimes it'll successfully detect the chip and then "fatal error occurred: Timed out waiting for packet header". Very rarely it'll get to "Uploading stub..." before "Failed to enter RAM download mode (result was 0105)", or even more rarely "Failed to write to target RAM (result was 0107)"
Of the 9 functional chips, only two of them were ever able to interact with the bootloader, able to get the chip id and whatnot, and eventually (after many failed attempts) flashed a new firmware, so I know that, fundamentally, my setup is correct. 2 of 9 (eventually) successfully flashed, and the other 7 are effectively non-responsive to any interaction at all. I since accidentally burned out the one working one, and then crammed the other into a box with a power supply and it's now a tiny wifi repeater, so at least one project is a success, but I'd like to repeat that success 7 more times.
At first I suspected a UART issue, so I tried a bunch of different baud rates with no change. I wrote a quick script to download a 1MB file from a local server and write it out on the serial port and it came out perfectly on several attempts every time so I feel like I can rule out UART problems.
One other thing, I was lead to believe that the bootloader starts at a baud rate of 74880, and if you open a terminal and power it on you'll see some text indicating boot mode and other information; there is no such text, it's just gibberish, seemingly random values for all 9 of them, even the 2 that worked. Is this perhaps not the right baud rate?
This is a sample of what I run:
$ esptool.py --port /dev/ttyUSB0 -b 57600 --before no_reset --after no_reset chip_id
esptool.py v2.3.2-dev
Connecting....
Detecting chip type... ESP8266
A fatal error occurred: Timed out waiting for packet header
edit: After experimenting long into the night I finally found out that terminal applications (ie screen and minicom) don't work, presumably rejecting the 74880 and falling back on 9600, but by using python's serial module I am able to read the status correctly, so here's all the results of one of the chips. All pullups are through a 3k3 resistor.
With 15 low, 2 high, 0 high, CH_PD high: ets Jan 8 2013,rst cause:1, boot mode:(3,7)
With 15 low, 2 high, 0 low, CH_PD high: ets Jan 8 2013,rst cause:1, boot mode:(1,7)
Do those look right?
Actually, leaving 15, 2, 0, and CH_PD all floating I still get (3,7) so I'm guessing the board it's soldered to has pullups/downs as required.
As a first test I intended to build a simple wifi repeater: found a guide, wired one up, downloaded the prebuilt firmware, attempted to flash... and failure after failure.
For background, these are all ESP8266-07 or -12 I think, with ceramic antennas and 4Mb of flash. I'm running Linux using esptool.py. Even basic commands, like read_mac and flash_id fail. Sometimes it'll just spin at "Connecting...." until it times out; sometimes it'll successfully detect the chip and then "fatal error occurred: Timed out waiting for packet header". Very rarely it'll get to "Uploading stub..." before "Failed to enter RAM download mode (result was 0105)", or even more rarely "Failed to write to target RAM (result was 0107)"
Of the 9 functional chips, only two of them were ever able to interact with the bootloader, able to get the chip id and whatnot, and eventually (after many failed attempts) flashed a new firmware, so I know that, fundamentally, my setup is correct. 2 of 9 (eventually) successfully flashed, and the other 7 are effectively non-responsive to any interaction at all. I since accidentally burned out the one working one, and then crammed the other into a box with a power supply and it's now a tiny wifi repeater, so at least one project is a success, but I'd like to repeat that success 7 more times.
At first I suspected a UART issue, so I tried a bunch of different baud rates with no change. I wrote a quick script to download a 1MB file from a local server and write it out on the serial port and it came out perfectly on several attempts every time so I feel like I can rule out UART problems.
One other thing, I was lead to believe that the bootloader starts at a baud rate of 74880, and if you open a terminal and power it on you'll see some text indicating boot mode and other information; there is no such text, it's just gibberish, seemingly random values for all 9 of them, even the 2 that worked. Is this perhaps not the right baud rate?
This is a sample of what I run:
$ esptool.py --port /dev/ttyUSB0 -b 57600 --before no_reset --after no_reset chip_id
esptool.py v2.3.2-dev
Connecting....
Detecting chip type... ESP8266
A fatal error occurred: Timed out waiting for packet header
edit: After experimenting long into the night I finally found out that terminal applications (ie screen and minicom) don't work, presumably rejecting the 74880 and falling back on 9600, but by using python's serial module I am able to read the status correctly, so here's all the results of one of the chips. All pullups are through a 3k3 resistor.
With 15 low, 2 high, 0 high, CH_PD high: ets Jan 8 2013,rst cause:1, boot mode:(3,7)
With 15 low, 2 high, 0 low, CH_PD high: ets Jan 8 2013,rst cause:1, boot mode:(1,7)
Do those look right?
Actually, leaving 15, 2, 0, and CH_PD all floating I still get (3,7) so I'm guessing the board it's soldered to has pullups/downs as required.