flash: fix retry corruption for compressed writes and cap ESP32 baud rate - #59
Merged
Conversation
…rate After a timeout during a compressed flash write, the retry's SLIP frame (starting with 0xC0) would terminate the stub's partial frame and then deliver the full retry data in the same write. The stub processed both as separate commands: it emitted a stale error for the truncated frame, then silently decompressed and wrote the retry block then advancing the zlib decompressor state. The host only read the stale error, flushed the real ACK, and retried with the same block, which the decompressor could no longer handle, causing all subsequent retries to hang. Fix by sending a bare 0xC0 to terminate the partial frame as a separate write, then waiting 50ms for the stale error response to arrive before flushing and retrying. This keeps the retry data out of the cleanup sequence and preserves consistent decompressor state. Also: - Add MaxUARTFlashBaud field to chipDef; set to 230400 for ESP32 to prevent UART RX FIFO overflow on USB-UART bridges (CH340, CP2102) - Increase flash block retries from 3 to 5 to provide headroom after the stale-frame cleanup cycle consumes one attempt Signed-off-by: deadprogram <ron@hybridgroup.com>
On Linux, signals such as SIGWINCH (terminal resize) can interrupt write(2) and tcdrain(3) on serial file descriptors, causing them to return EINTR before any bytes are transferred. The go.bug.st/serial library does not retry internally, so the error bubbles up as "interrupted system call" and aborts the flash. Wrap port.Write and port.Drain in sendCommand with EINTR retry loops so transient signal interruptions are handled transparently. Fixes a "send command 0x12: interrupted system call" failure observed during compressed flash download on ESP32-C3 (USB-JTAG/Serial). Signed-off-by: deadprogram <ron@hybridgroup.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After a timeout during a compressed flash write, the retry's SLIP frame (starting with 0xC0) would terminate the stub's partial frame and then deliver the full retry data in the same write. The stub processed both as separate commands: it emitted a stale error for the truncated frame, then silently decompressed and wrote the retry block then advancing the zlib decompressor state. The host only read the stale error, flushed the real ACK, and retried with the same block, which the decompressor could no longer handle, causing all subsequent retries to hang.
Fix by sending a bare 0xC0 to terminate the partial frame as a separate write, then waiting 50ms for the stale error response to arrive before flushing and retrying. This keeps the retry data out of the cleanup sequence and preserves consistent decompressor state.
Also:
UPDATE: added a second commit to handle retry of serial Write and Drain on EINTR to fix a "send command 0x12: interrupted system call" failures observed during compressed flash download on ESP32-C3 (USB-JTAG/Serial).