Sometimes fails with compression allowed.

[mike-s123]

Is your feature request related to a problem? Please describe.
esptool.py can fail when uploading some images if compression is allowed: A fatal error occurred: Timed out waiting for packet header

Describe the solution you'd like
Using --no-compress resolves the issue, but a configurable timeout period may solve the issue without the impact on upload time that --no-compress causes.

Additional context
Steps used in troubleshooting here.

[dobairoland]

Hi @mike-s123. Thank you for reporting this.

Could you please try to increase the timeout here by increasing 2? It would be interesting to know approximately at what value would start to work for you (if it would at all). Thank you!

[mike-s123]

@dobairoland Changing the multiplier to 3 resulted a successful upload without disabling compression.

esp.flash_defl_block(block, seq, timeout=DEFAULT_TIMEOUT * ratio * 3)

[dobairoland]

Thank you @mike-s123 for the feedback. We will submit a fix.

[lorol]

@mike-s123
Great!
I already started to dig in adding a checkbox to the UI :) as workaround but don't have enough Java/ArduinoIDE/Tools/UI experience to made it quick, neither an environment to see the dialogs ... just blindly tests :)

[mike-s123]

@dobairoland I did some more testing. When I tested earlier, with the multiplier at 3, it worked twice in a row (would fail 100% before). But doing some more uploads I would still get occasional timeout errors (1/4 of the time?). Measuring how long the upload paused - it was usually about 17 seconds, but sometimes over 21. (I added a print to see that esptool.py was setting the timeout to 21 seconds.)

So I did some more testing. changing it to 3.5 (timeout 24), I got a failure before I got to 10 tries. I upped the multiplier to 4 (timeout 28). Uploads were successful 25/25.

I just happened to find an image which caused these delays which triggered the timeout error. I have no way of knowing if it is the worst case (probably not). It may make sense to change the multiplier to 5. I don't see any disadvantage except taking longer to recognize a legitimate failure, which should be rare.

Results:

Multiplier	Failure rate
2(current)	100%
3	25%
3.5	10%?
4	0% (25 tests)

[dobairoland]

Hi @mike-s123.

I really appreciate the time you've taken to run those tests.

I'm now testing the following formula to compute the delay:

esp.flash_defl_block(block, seq, timeout=timeout_per_mb(3, uncsize))

This should give longer timeout in your case than:

esp.flash_defl_block(block, seq, timeout=DEFAULT_TIMEOUT * ratio * 5)

[mike-s123]

@dobairoland On my test file, that results in a timeout of 40, more than the 35 a multiplier of 5 provides. It's good for me, I'll defer to your knowledge of what it's fundamentally based on. Thanks.

[neinseg]

I have this same issue using esptool 3.0 on an 1MB SPI flash "ESP-01" esp8266 module at 115200Bd. The image is an empty 64kB SPIFFS, so highly compressible. When I run esptool.py without --no-compress, it transfers the image almost instantly, then waits a few seconds and prints the timeout error message. When ran with --no-compress, it shows the progress indicator for ~10s, then waits a second or two and exists with "Leaving...".