harden USB telemetry transport

This commit is contained in:
Jay
2026-08-17 14:51:12 -04:00
parent 1cf0a9ac77
commit 3c95f3d7be
17 changed files with 709 additions and 114 deletions
+17 -9
View File
@@ -88,15 +88,23 @@ the oldest retained data is sent first. If the queue fills, acquisition drops
new samples rather than overwriting older ones; sequence gaps and the cumulative
lost-sample counter expose that permanent loss.
That retry guarantee requires the transport's success result to mean that the
complete frame was accepted for eventual delivery. The current USB Serial/JTAG
VFS/stdio path does not fully satisfy that contract: if the host remains
connected but stops draining, its internal timeout can discard bytes while the
stdio write appears successful. CRC and sequence checks make that loss visible
to a receiver, but it does not increment the device's drop counter. A direct
driver path with bounded transmit-drain waits can report this condition; an
application acknowledgement and replay window is required for end-to-end
delivery confirmation.
The shared transport state machine distinguishes three nonfatal states. `RETRY`
means zero bytes were accepted and the complete frame may be submitted again.
`PENDING` means the backend owns an in-flight frame, so firmware may only poll
that transfer. `COMPLETE` permits the output task to reuse its packet buffer and
consume more samples. This prevents a timeout after partial progress from
causing an ambiguous whole-frame duplicate.
The direct USB Serial/JTAG backend atomically copies a complete frame into its TX
ring, then polls a bounded transmit-drain wait. A timeout remains `PENDING`; it
does not trigger resubmission. This closes the VFS/stdio path's silent-discard
case for a connected host that stops draining.
USB drain is not end-to-end application delivery confirmation. A host process
may attach after earlier frames have already left the endpoint, or fail after
the endpoint accepts them. CRC and sequence checks make resulting loss visible,
but an application acknowledgement and replay window are still required to
guarantee receipt.
Receivers report bytes left in an incomplete trailing frame when capture ends.
Those bytes cannot pass CRC validation and are not silently admitted as samples.