Closed dominikzaq closed 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?
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.
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?
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.
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.
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...