Can't erase_flash/write_flash: Timed out waiting for packet header (ESPTOOL-353) #120

OrganicIrradiation · 2016-08-24T03:24:10Z

I've been having lots of issues trying to reflash a Wemos D1 mini (ESP-12F, CH340G USB<->Serial, 4M bytes flash). I was previously able to flash it with the Arduino IDE, but after trying to reflash it with the micropython distribution, it seems as though I've soft-bricked it.

I get the following error with esptool.py when trying to erase the flash:

$ esptool.py --port /dev/tty.wchusbserial1410 erase_flash
esptool.py v1.1
Connecting...
Erasing flash (this may take a while)...

A fatal error occurred: Timed out waiting for packet header

If I try to write_flash, I get the same error:

$ esptool.py --port /dev/tty.wchusbserial1410 --baud 115200 write_flash --flash_size=32m -fm dio 0 esp8266-20160823-v1.8.3-41-g253e1a6.bin
esptool.py v1.1
Connecting...
Running Cesanta flasher stub...
Flash params set to 0x0240
Writing 532480 @ 0x0... 
A fatal error occurred: Timed out waiting for packet header

I'm able to read the chip_id and MAC, but apparently not the flash_id:

$ esptool.py --port /dev/tty.wchusbserial1410 chip_id
esptool.py v1.1
Connecting...
Chip ID: 0x00------
$ esptool.py --port /dev/tty.wchusbserial1410 read_mac
esptool.py v1.1
Connecting...
MAC: 5c:cf:7f:--:--:--
$ esptool.py --port /dev/tty.wchusbserial1410 flash_id
esptool.py v1.1
Connecting...

A fatal error occurred: Timed out waiting for packet header

If I connect with a serial terminal at 74880 baud I can see the module communicates from the bootloader:

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

I've tried on Mac OS X 10.11.6 (with the signed driver) and on a Windows 10 machine (with automatically installed driver), both with the same results. I've also tried with virtual machines and a multitude of cables. Nothing seems to reflash it (I've tried esptool.py, esptool-ck, NodeMCU Flasher, and the espressif flash tool).

Any suggestions??

The text was updated successfully, but these errors were encountered:

OrganicIrradiation · 2016-08-24T16:23:47Z

Fixed by putting a 10 Ohm resistor between pins D3 (DIO 0) and GND! Seems as though the reset & programming circuit's pull-down timing is off (see right side of USB to UART section of the Wemos D1 mini schematic)

$ esptool.py --port /dev/tty.wchusbserial1410 --baud 115200 write_flash --flash_size=32m -fm dio 0 esp8266-20160823-v1.8.3-41-g253e1a6.bin
esptool.py v1.1
Connecting...
Running Cesanta flasher stub...
Flash params set to 0x0240
Writing 532480 @ 0x0... 532480 (100 %)
Wrote 532480 bytes at 0x0 in 46.1 seconds (92.4 kbit/s)...
Leaving...

projectgus · 2016-08-25T10:56:05Z

Thanks for posting an update. The circuit used on the D1 is very common on ESP8266 dev boards, so I think maybe Q1 or R7 on your board may not be soldered right.

However, if anyone else also runs across this problem on OS X then it could still be a timing issue from esptool.py, so feel free to comment.

OrganicIrradiation · 2016-08-25T17:03:42Z

I believe flashing v1.8.3 of micropython introduced the issue (from the binary on micropython.org).

I was able to clear up lingering issues and can now re-upload Arduino without the additional resistor (between GND and DIO 0) by clearing the flash, re-uploading the boot binary (not sure if this matters), and then doing an initial upload with the Arduino IDE:

# For each run of esptool.py, make sure 10 Ohm resistor is between DIO 0 and
# GND and unplug/reattach after each successful completion:
$ esptool.py --port /dev/tty.wchusbserial1420 erase_flash

# Get blank_1MB.bin from http://www.pratikpanda.com/completely-format-erase-esp8266-flash-memory/
$ esptool.py --port /dev/tty.wchusbserial1420 --baud 115200 write_flash --verify --flash_mode=dio --flash_size=32m 0x00000 blank_1MB.bin 0x10000 blank_1MB.bin 0x20000 blank_1MB.bin 0x30000 blank_1MB.bin

$ esptool.py --port /dev/tty.wchusbserial1420 erase_flash

# Get boot_v1.6.bin from https://github.com/tommie/esp8266_nonos_sdk
$ esptool.py --port /dev/tty.wchusbserial1420 --baud 115200 write_flash --verify --flash_mode=dio --flash_size=32m 0x00000 boot_v1.6.bin

# Flash with Arduino IDE, then unplug and remove resistor.
# Should be able to reflash without using the programming resistor.

dgonzalez870 · 2018-02-11T16:04:59Z

I have same problem with a lolin V3 board. I can read chip_Id, MAC, flash, when I try to read the flash_id it seems to return a wrong value: Manufacturer: 00, Device: 0000, Detected flash size: Unknown and when i try to write a binary of Nodemcu generated from the cloud build service produces A fatal error occurred: Timed out waiting for packet content

I have the following results:

Read mac

 > py .\esptool.py -p com4 -b 9600 read_mac
esptool.py v2.3-dev
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
MAC: 5c:cf:7f:13:34:8e
Hard resetting...

Read Chip ID

> py .\esptool.py -p com4 -b 9600 chip_id
esptool.py v2.3-dev
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Chip ID: 0x0013348e
Hard resetting...

Read Flash ID

> py .\esptool.py -p com4 -b 9600 flash_id
esptool.py v2.3-dev
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Manufacturer: 00
Device: 0000
Detected flash size: Unknown
Hard resetting...

Read Flash

> py .\esptool.py -p com4 -b 9600 read_flash 0 16777216 esp_flash_content.txt

esptool.py v2.3-dev
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
16777216 (100 %)
16777216 (100 %)
Read 16777216 bytes at 0x0 in 1528.4 seconds (87.8 kbit/s)...
Hard resetting...

Write flas

> py .\esptool.py -p com4 -b 9600 write_flash 0 nodemcu.bin
esptool.py v2.3-dev
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0x0, SizeID=0x0), defaulting to 4MB
Flash params set to 0x0240
Compressed 401328 bytes to 258738...

A fatal error occurred: Timed out waiting for packet content

projectgus · 2018-02-13T04:03:33Z

when I try to read the flash_id it seems to return a wrong value: Manufacturer: 00, Device: 0000, Detected flash size: Unknown

This indicates the flash chip (inside the metal can on the board) isn't responding at all to the ESP chip.

Try removing your development board from the breadboard. Sometimes breadboards can short the SPI flash pins on the board and cause this kind of problem.

If it's the same with the board totally disconnected from the breadboard then you have a faulty development board. The quickest solution is probably to replace it.

badbyt3 · 2019-04-14T21:33:14Z

I have upgraded a sonoff s20 with a winbond w25q128fv but i fail at flashing it.
Is there anything that I'm missing out here?

projectgus · 2019-04-15T00:11:59Z

@badbyt3 Impossible to say without more information. Please open a new issue with the full command line and output from esptool.py, and as many relevant details as possible.

MichaelVoelkel · 2019-05-25T17:47:32Z

I believe flashing v1.8.3 of micropython introduced the issue (from the binary on micropython.org).

I was able to clear up lingering issues and can now re-upload Arduino without the additional resistor (between GND and DIO 0) by clearing the flash, re-uploading the boot binary (not sure if this matters), and then doing an initial upload with the Arduino IDE:

# For each run of esptool.py, make sure 10 Ohm resistor is between DIO 0 and
# GND and unplug/reattach after each successful completion:
$ esptool.py --port /dev/tty.wchusbserial1420 erase_flash

# Get blank_1MB.bin from http://www.pratikpanda.com/completely-format-erase-esp8266-flash-memory/
$ esptool.py --port /dev/tty.wchusbserial1420 --baud 115200 write_flash --verify --flash_mode=dio --flash_size=32m 0x00000 blank_1MB.bin 0x10000 blank_1MB.bin 0x20000 blank_1MB.bin 0x30000 blank_1MB.bin

$ esptool.py --port /dev/tty.wchusbserial1420 erase_flash

# Get boot_v1.6.bin from https://github.com/tommie/esp8266_nonos_sdk
$ esptool.py --port /dev/tty.wchusbserial1420 --baud 115200 write_flash --verify --flash_mode=dio --flash_size=32m 0x00000 boot_v1.6.bin

# Flash with Arduino IDE, then unplug and remove resistor.
# Should be able to reflash without using the programming resistor.

I had to change two things in step 2: 0x10000 overlapped according to the tool, but I could add a 0 there and also for 0x2... 0x3...

Also, it does not work if I enter this baud rate. If I leave the baud rate, it's fine.

Nevertheless, flashing via Arduino IDE does only work if I switch to 5V (maybe, because it needs more amps and more voltage also increases this? not sure). But even then, I need to reconnect power to ESP8266 to flash again

MichaelVoelkel · 2019-05-25T18:02:13Z

watch this video on youtube and u will get it, i suffered from the same problem too but this video resolved the problem, anyways thanks me later, the link is below:
https://youtu.be/ji71cHaGW8w

This video does not address any troubleshooting at all. Everything works there right away

furqan4545 · 2019-05-26T10:50:06Z

ops soory, I posted the solution on the wrong page, actually i had multiple pages opened consecutively.

…

On Sat, May 25, 2019 at 11:02 PM IceMichael ***@***.***> wrote: watch this video on youtube and u will get it, i suffered from the same problem too but this video resolved the problem, anyways thanks me later, the link is below: https://youtu.be/ji71cHaGW8w This video does not address any troubleshooting at all. Everything works there right away — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#120?email_source=notifications&email_token=AL7UYYDTHFQP2TTLVWM64ZLPXF5K7A5CNFSM4CNOM2Q2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWHWNQI#issuecomment-495937217>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL7UYYCDUSSJ3HYGWOF7PCLPXF5K7ANCNFSM4CNOM2QQ> .

badbyt3 · 2019-05-26T11:12:26Z

@Elypson thx for the comment. It came a little late because I tried to replace the flash with another chip where I accidentally ripped off a solder pad. :(
Yet I will keep that mind for the next time I run into such a problem.

projectgus · 2019-05-27T05:03:20Z

Hi @Elypson ,

I'm glad you got things working. FWIW, most of the steps you posted should not be necessary. One erase_flash command should be enough to erase the entire flash chip provided it succeeds and doesn't error out. Writing the "blank.bin" files and then erasing a second time is all redundant.

I don't know how the 2016 MicroPython 1.8.3 release could have messed up the ESP8266 enough that it could't be recovered via esptool.py. Older versions of esptool.py will fail if the chip is in deep sleep (#351) but this is no longer an issue as of esptool.py v2.6.

I would expect that any failure of esptool.py v2.6 to flash is due to a hardware problem. If the ESP8266 doesn't boot the firmware correctly after flashing, then a single "erase_flash" command may help remove any data which is leftover from older firmware.

Damiortiz · 2020-01-07T11:57:03Z

I tried all the things I saw on the Internet. The only solution that worked was this.

Press the flash and RST button at the same time for a few seconds.
Release only the RST button
Without releasing the FLASH button upload the code with NodeMCU version 1.0

I hope someone will use it!

Klarkin2 · 2020-12-07T22:30:25Z

I tried all the things I saw on the Internet. The only solution that worked was this.
Press the flash and RST button at the same time for a few seconds.
Release only the RST button
Without releasing the FLASH button upload the code with NodeMCU version 1.0
I hope someone will use it!

This worked for me, thanks for sharing!

gfea · 2021-11-16T13:56:24Z

I tried all the things I saw on the Internet. The only solution that worked was this.
Press the flash and RST button at the same time for a few seconds.
Release only the RST button
Without releasing the FLASH button upload the code with NodeMCU version 1.0
I hope someone will use it!

work for me

OrganicIrradiation closed this as completed Aug 24, 2016

dehart mentioned this issue Apr 13, 2018

erase_flash command timing out after 120 seconds #300

Closed

github-actions bot changed the title ~~Can't erase_flash/write_flash: Timed out waiting for packet header~~ Can't erase_flash/write_flash: Timed out waiting for packet header (ESPTOOL-353) Nov 16, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Can't erase_flash/write_flash: Timed out waiting for packet header (ESPTOOL-353) #120

Can't erase_flash/write_flash: Timed out waiting for packet header (ESPTOOL-353) #120

OrganicIrradiation commented Aug 24, 2016

OrganicIrradiation commented Aug 24, 2016

projectgus commented Aug 25, 2016

OrganicIrradiation commented Aug 25, 2016

dgonzalez870 commented Feb 11, 2018

projectgus commented Feb 13, 2018 •

edited

Loading

badbyt3 commented Apr 14, 2019

projectgus commented Apr 15, 2019

MichaelVoelkel commented May 25, 2019 •

edited

Loading

MichaelVoelkel commented May 25, 2019

furqan4545 commented May 26, 2019 via email

badbyt3 commented May 26, 2019

projectgus commented May 27, 2019

Damiortiz commented Jan 7, 2020

Klarkin2 commented Dec 7, 2020

gfea commented Nov 16, 2021

Can't erase_flash/write_flash: Timed out waiting for packet header (ESPTOOL-353) #120

Can't erase_flash/write_flash: Timed out waiting for packet header (ESPTOOL-353) #120

Comments

OrganicIrradiation commented Aug 24, 2016

OrganicIrradiation commented Aug 24, 2016

projectgus commented Aug 25, 2016

OrganicIrradiation commented Aug 25, 2016

dgonzalez870 commented Feb 11, 2018

projectgus commented Feb 13, 2018 • edited Loading

badbyt3 commented Apr 14, 2019

projectgus commented Apr 15, 2019

MichaelVoelkel commented May 25, 2019 • edited Loading

MichaelVoelkel commented May 25, 2019

furqan4545 commented May 26, 2019 via email

badbyt3 commented May 26, 2019

projectgus commented May 27, 2019

Damiortiz commented Jan 7, 2020

Klarkin2 commented Dec 7, 2020

gfea commented Nov 16, 2021

projectgus commented Feb 13, 2018 •

edited

Loading

MichaelVoelkel commented May 25, 2019 •

edited

Loading