espressif / esptool

Espressif SoC serial bootloader utility
https://docs.espressif.com/projects/esptool
GNU General Public License v2.0
5.57k stars 1.38k forks source link

error 0x05, retransmission does not work during programming(ESP 8266) #428

Closed dominikzaq closed 5 years ago

dominikzaq commented 5 years ago

I'm tried to send the same frame twice time and I received error. [192, 1, 3, 2, 0, 7, 7, 18, 32, 1, 5, 192] so retransmission not working properly. I can not send the same frame more than once. I want to know if there is any way to recover the programming process after the ESP hits an error. I tried to send the frame again but this way does not work. Maybe arduino has a frame counter...

projectgus commented 5 years ago

Sorry, I don't understand what you mean by "retransmission" or what this error means.

Are you using esptool.py? Have you modified it in some way?

dominikzaq commented 5 years ago

in esptool i added below code

esp.flash_block(block, seq)
time.sleep(1)
esp.flash_block(block, seq)

Logs send [192, 0, 3, 16, 1, 66, 0, 0, 0, 0, 1... receive[1, 3, 2, 0, 239, 64, 22, 0, 0, 0] send[192, 0, 3, 16, 1, 66, 0, 0, 0, 0, 1... receive[1, 3, 2, 0, 239, 64, 22, 0, 1, 5]

error in console: A fatal error occurred: Failed to write to target Flash after seq 0 (result was 0105)

so this mean that i can't send twice time this same frame, I want to be 100% sure that the package has arrived.

projectgus commented 5 years ago

For the SPI flash attached to the ESP8266, you have to erase each sector of flash before you write it.

The stub loader does a number of optimisations to speed up flashing, including erasing each sector of data ahead of writing it. This is why it only supports receiving each block in sequence, and sees an out-of-order block as invalid data. (The non-stub-loader erases all the flash at the beginning. I don't know if it will allow you to send each block of data twice, but doing it will not help as the flash is not erased twice.)

What problem are you trying to solve?

projectgus commented 5 years ago

I see now that you're trying to solve the problem of recovering from serial errors.

Just sending the data twice isn't enough because of the erase/write requirement. If bad data is written once, writing again won't change it.

It may be possible to retry a corrupt packet when the ESP sends an error code back, but it will probably require error handling code on the stub loader side as well, so the state is wound back correctly.

dominikzaq commented 5 years ago

"i'm sending data via TCP(i modified esptool), and sometimes i'm not receive answer. " MY PROBLEM

  1. I'm sending frame to arduino with esptool via tcp 2 Arduino sending good frame via tcp to esptool
  2. Frame lost in network 4.Is it possible to ask again if arduino got a frame
projectgus commented 5 years ago

TCP is a reliable transport protocol. So I don't think you're losing data in the TCP stream itself, unless the connection is terminating and you're opening a new TCP connection.

Possibly this is some timing issue - ie bytes are being sent to the ESP8266 with unexpected timing, and this results in an error.

Unfortunately if you've modified esptool then this is outside the scope of what we can support. Note that esptool.py already has support for serial-over-TCP using RFC2217.

If you can reproduce the problem with unmodified esptool.py and an RFC2217 server, please open a new issue with the details.