Bridge link fixes - #1631
Open
kareltucek wants to merge 10 commits into
Open
Bridge link fixes#1631kareltucek wants to merge 10 commits into
kareltucek wants to merge 10 commits into
Conversation
Frame/ack/resend counters, RX stop reasons, and ack latency histograms (sender: uart_tx -> ack parsed; receiver: frame parsed -> ack handed to uart_tx). Printed by 'uhk uartStats' and included in the 'uhk recover' dump. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
After any RX teardown, bridgeOnRxDisabled resyncs the parser while the peer's frame may still be streaming in; the rest of it arrived as 'unexpected' bytes, each of which reset RX again (10ms deaf, mid-frame re-enable) until the frame ended. Let the parser resync on the next Start byte instead, as the low-power build already did. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Restore the watermark check removed in 8d055e5: a frame whose ack got lost is resent with the same watermark and must not be applied twice (left key states carry cursor deltas). rxIdxValid exempts the first frame after a local watermark reset. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The ack loop is ~3ms for a key-state frame and ~13ms for a maximum-length one; every retry blinds the left key scanner for the whole delay. Backoff still doubles per retry. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
shared/uart_parser.c never included debug.h, so the flag was undefined there and the byte-corruption block was compiled out regardless of its value (since a689d1f). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
uart_tx stores the buffer pointer and returns; EasyDMA reads it afterwards. Control bytes (Ack/Nack/Ping) and the wake byte were sent from stack variables that went out of scope before the transfer, so what reached the wire was not guaranteed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The CRC-invalid dump ran in the UART RX ISR and emitted one deferred log message per byte; a single bad frame overflowed the log buffer regardless of log thread priority. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The exponential backoff let one unacked frame hold txBufferBusy for ~1s (was ~8s at 64ms); on the left half that blocks the key scanner, so key changes made meanwhile are coalesced or lost. Worst case is now UART_RESEND_COUNT * UART_RESEND_DELAY = 45ms. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Under DEBUG_STRESS_UART, ack/nack/ping bytes are discarded with ~5% probability, so the timeout -> resend -> duplicate path gets exercised, not only CRC failures. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This branch has not been deployed
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
1 participant
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.
Changelog:
In detail:
Hypothesis: Timing change in the SDK made acknowledge bytes get lost frequently on some units, because control bytes were not double buffered. Normal send from key scanner doesn't block, however, second key change send will block until the first send's ack is delivered. With resend delay 64ms this already postulates 64ms stalls whenever an ack gets lost. If third state change arrives in this interval, it doesn't get scanned and may even be missed entirelly.