Can't flash with stub when device in deep sleep

[marcelstoer]

Condensed version of earlier discussions.

• Operating system: macOS
• Python version: 2.7/3.6
• ESP hardware in use: ESP-WROOM-02, ThingPulse ESPaper Lite Kit module: https://thingpulse.com/wp-content/uploads/2018/01/PCBBackReflectionWithLegend.jpg
• USB-to-serial: CP2101-based

!! The device is in deep sleep (the previously loaded app triggered this) when the flash process started. Flash mode is enabled, though. !!

Full esptool.py command line as run:

esptool.py --port /dev/cu.SLAB_USBtoUART --baud 921600 write_flash --flash_size 2MB --flash_mode qio 0x00000 myapp.ino.bin

Full output from esptool.py

esptool.py v2.5.0
Serial port /dev/cu.SLAB_USBtoUART
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 60:01:94:21:ca:1c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Compressed 418176 bytes to 287752...

A fatal error occurred: Timed out waiting for packet content

What is the expected behaviour?

Binary flashed to device.

Do you have any other information from investigating this?

Enabling trace mode shows these few lines before the process aborts:

...
Compressed 418176 bytes to 287752...
TRACE +0.057 command op=0x10 data len=16 wait_response=1 timeout=3.000
data=80610600120000000040000000000000
TRACE +0.000 Write 26 bytes:
    c000101000000000 0080610600120000 | ..........a.....
    0000400000000000 00c0             | ..@.......
TRACE +0.001 Read 1 bytes: c0
TRACE +0.000 Read 1 bytes: 01
TRACE +0.001 Read 1 bytes: 10
TRACE +0.000 Read 6 bytes: 020000000000
TRACE +3.003 Timed out waiting for packet content

A fatal error occurred: Timed out waiting for packet content

Is there any other information you can think of which will help us reproduce this problem?

It works with esptool-ck
Uploading from within Arduino IDE has never been an issue. esptool-ck is a bit slow but other than that pretty reliable. It even uploads the binary when the device is in deep sleep.

It works w/o the stub
esptool.py --port /dev/cu.SLAB_USBtoUART --baud 921600 --no-stub write_flash ... is a workaround - a slow one, though:

esptool.py v2.5.0
Serial port /dev/cu.SLAB_USBtoUART
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 60:01:94:21:ca:1c
WARNING: ROM doesn't support changing baud rate. Keeping initial baud
rate 115200
Enabling default SPI flash mode...
Configuring flash size...
Erasing flash...
Took 2.12s to erase flash block
Wrote 418816 bytes at 0x00000000 in 42.0 seconds (79.8 kbit/s)...

Leaving...
Hard resetting via RTS pin...

Fine w/o deep sleep
To work around this you need to unplug USB, replug it, and then put the device into flash mode before the currently loaded app can run and put it into deep sleep.

Flash settings make no difference
I tried Python 2.7/3.6, different esptool.py version, different baud rates, different flash modes, auto-flash size on/off - the behavior is consistent.

[marcelstoer]

@igrr Ivan, maybe you can help Angus with this by bringing in the expertise of the esptool-ck maintainer.

[igrr]

@marcelstoer do you see this behavior with any common board, e.g. NodeMCU?

[marcelstoer]

That was next on my list anyhow but yes, I can reproduce this on a NodeMCU V2/1.0.

[marcelstoer]

@igrr / @projectgus is there anything I can do to make your life easier in reproducing and fixing this? Is there any further information I could provide? Any chance to get a fix for this soonish?

[davydnorris]

I think I have pretty much confirmed this is my problem too, but up until a couple of weeks ago I had been flashing deep sleep enabled code with no problem.

I can also add that the nodemcu flasher also works every time, but the Espressif GUI based flash tool has the same issue as esptool.

[projectgus]

@marcelstoer Thanks for being patient while one of us got to this.

I was able to reproduce and create a test case (see commit) so I'm pretty sure this is fixed now, but please ping if you're still experiencing problems.

[marcelstoer]

The few tests were successful, thanks. Do you have an ETA for the upcoming release?

[projectgus]

@marcelstoer Awesome! This week, I hope.