Restore Sonoff SV saved firmware fail

[djsomi]

Operating system

Windows 10

Python version

3.8.0

What Chip

ESP8266EX

Are you running esptool.py from an IDE such as Arduino or Eclipse?

Example: No IDE, Windows command prompt

Full esptool.py command line that was run:

c:\esptool>esptool.py --port COM7 --baud 115200 write_flash -fs 1MB -fm dout -ff 40m 0x0 sonoff_sv6.bin

Full output from esptool.py

esptool.py v2.8
Serial port COM7
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: bc:dd:c2:44:86:c1
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0320
Compressed 1048576 bytes to 319796...
Wrote 1048576 bytes (319796 compressed) at 0x00000000 in 34.6 seconds (effective 242.6 kbit/s)...

A fatal error occurred: Timed out waiting for packet header

---

Hi All,

I saved a sonoff SV oem firmware with the following command:

• esptool.py --port COM7 read_flash 0x00000 0x100000 sonoff_sv6.bin
• flashed HAA latest version (working fine)
• I want to restore saved oem fw file > got an error while writing it back: (to the same device where it is saved from)

c:\esptool>esptool.py --port COM7 --baud 115200 write_flash -fs 1MB -fm dout -ff 40m 0x0 sonoff_sv6.bin
A fatal error occurred: Timed out waiting for packet header

I can flash HAA back, and its woriking fine, but cannot go back to ewelink fw.

Anyone experinced same issue?

Many Thanks

[projectgus]

Hi @djsomi ,

It looks like the file finished flashing successfully but the timeout happens when trying to read back the value. Does the Sonoff work as expected despite the error?

If you're able to reproduce this, please try two different command lines to narrow down the problem:

• esptool.py --port COM7 --baud 115200 write_flash --no-compress -fs 1MB -fm dout -ff 40m 0x0 sonoff_sv6.bin <-- does the error still occur with --no-compress?
• esptool.py --trace --port COM7 --baud 115200 write_flash -fs 1MB -fm dout -ff 40m 0x0 sonoff_sv6.bin <-- this will dump a lot of output, could you please post the last 10-20 lines or so?

[djsomi]

Hi @projectgus ,

Thanks for your help --no-compress solved this issue!
(Just for curiosity, what can be the reason behind this?)

Many Thanks
Zoli

[projectgus]

Good to hear, @djsomi . Will keep this open because it still shouldn't be timing out in any case.

(Just for curiosity, what can be the reason behind this?)

I don't know for sure but this is my guess:

Compressed 1048576 bytes to 319796...
Wrote 1048576 bytes (319796 compressed) at 0x00000000 in 34.6 seconds (effective 242.6 kbit/s)...

The compression ratio here is more than 3 to 1 (probably because a lot of the flash is unwritten 0xFFs). Probably a lot of the 0xFFs are at the end. This means that the last compressed packet sent over the UART may expand to a very large amount of data being written to the flash.

The flasher stub actually sends back an "ACK" as soon as it receives data over UART, not as soon as the data is written to the flash (this is done for performance reasons, it can receive the next packet of data while writing the last packet). This means the last compressed UART packet is ACKed quickly, but maybe it takes a very long time to actually write the expanded bytes out to the flash.

The flasher does take the overall compression ratio into account to calculate the timeout, but because this is the last packet it thinks that it's done and moves on to verifying the flash contents. This command times out, because the ESP8266 is actually still writing the very last set of data to flash.

Will do some tests to confirm this is actually what's happening.