Firmware stuck in wdt reset loop prevents flashing

[zgoda]

I have buggy firmware that enters wdt reset loop at some time. Once it enters the loop, there is no way to flash anything on this chip using esptool.py, operation ends with A fatal error occurred: Timed out waiting for packet header.

Ch. Klippel esptool (aka esptool-ck) works ok in such stuation.

[pfalcon]

You have some other issue in your serial communication chain. esptool.py can perfectly flash a chip stuck in no matter what. However, not every serial adapter, and even not every host-site driver for one, can handle any of possible weird conditions easily.

(That's mostly for @projectgus to confirm there's nothing wrong with esptool.py per se, though I myself reported various weird cases.)

[zgoda]

In both cases this is CH340G on Linux. Same board, same linux laptop.

[pfalcon]

CH340G

Somehow, I'm not surprised - the usual suspect.

[pfalcon]

the usual suspect.

E.g., this module is also CH340 based: pfalcon/yaota8266#7

[zgoda]

You might try esptool-ck, it is possible it will work in your case too.

[projectgus]

Hi @zgoda,

I have a few questions:

• What ESP8266 board are you using?
• Does it have the serial RTS/DTR connections for esptool.py to reset the board into the correct mode?
• Does esptool.py work correctly when the firmware is not stuck in the WDT reset loop?

If it's not a premade USB dev board (ESP8266 + CH340 in a single device) then could you please supply a photo of the hardware setup?

Angus

[zgoda]

Tried couple of other options so to recap:

• 2 boards with onboard CH340G do not flash (WeMos D1 mini clone and LoLin NodeMCU V3)
• board with onboard CP2102 does not flash (Amica NodeMCU V2)
• ESP-01 with PL2303 based USB-UART adapter does not flash
• ESP-01 with FT232R based USB-UART adapter does not flash

Other than in this particular case esptool.py works fine. ESP-01 does not have reset connection, 3 other boards reset fine after flashing.

[projectgus]

The same firmware fails on all this different hardware? That's interesting, as far as I know it shouldn't be possible to end up in a reset loop which can't be stopped via the hardware RST or EN line. Which the NodeMCU & WeMos D1 definitely have.

Is there any chance you could please send me the faulty firmware, in a way that I can trigger the bug to test? You can email me it directly (angus at espressif) if you don't want to post it publically.

[projectgus]

@zgoda Did you make any progress with this? Any chance you can (publically or privately) share the wdt-loop-inducing firmware or an esptool.py read_flash dump of the faulty chip?

[zgoda]

I will try to reproduce this. The bug in Sming that was the cause of this issue is long gone. Inducing WDT reset by simple long sleep does not produce this effect and firmware can be safely flashed. My guess is this should be very tight loop, when reset happens very early.

[projectgus]

It seems like #213 may be a symptom of the same kind of problem (I suggested a possible workaround there as well.)

If the reset-inducing timeout is delayed enough that esptool.py can take control of the chip, then we can probably make the correct register writes to disable it. Otherwise we may need to try and recover immediatelyt from the WDT-induced reset, hoping that the ESP8266 comes out of this into bootloader mode so we can then take control.

[sampreetg66]

can anyone give me a software link so as to flash a 8266

[projectgus]

I think this is probably fixed in esptool.py v2.6 with the fix for #351 and related issues. The version at the time also used the stub loader, and esptool-ck (working) does not use a stub loader, and this is probably at the root of the problem.

Please reopen if you still see this happening on v2.6.