docs: correct the TX diagnosis - it IS tx_bytes depth

A captured frame proves the full EXI->FPGA->W5100->wire path works: the first
16 bytes are byte-perfect (broadcast dst, PAR0-5 source MAC, ARP ethertype).
It truncates at exactly 16 = the tx_bytes FIFO depth, because TXFrameDrain
waits for a length that only arrives at the ST trigger, after the whole frame
has been streamed.

Supersedes the previous note, which concluded it was NOT depth-related; that
came from a clean-reset run whose result was invalid because the W5100 was
already wedged, so nothing transmitted regardless of length.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md

@@ -277,17 +277,37 @@ Pi over J4 with the board on 12 V — device ID `04 02 02 00`, NCRA reset
 self-clearing, PAR0–5, MAR0–7, ANALOG, NWAYC, IMR `0x86` readback, NCRA SR,
 and NWAYS `0x17`. See `hardware/re-bba-rb/exi_fullpath_rpi.py`.
 
-⚠️ **OPEN: GC→wire TX does not complete, and the W5100 is unresponsive.**
+✅ **GC→wire TX REACHES THE WIRE — the full path is proven.** A frame written
-Setting the NCRA ST bits never produces TI, and NCRA keeps reading back `0x0a`
+over EXI to TXDATA and triggered via the NCRA ST bits was captured on a PC:
-(ST never clears), for EVERY frame length 8…60 with a full NCRA reset between
+`ff ff ff ff ff ff | 00 09 bf 00 00 01 | 08 06 | 00 01` — broadcast dst, our
-attempts. The cause is NOT the EXI side and NOT `tx_bytes` depth (8-byte frames
+PAR0–5 source MAC and the ARP ethertype, all byte-perfect. So
-fail too): the **UART shell's own socket-3 `udp unicast` also hangs** — it
+EXI → BBARegisterFile → tx_bytes → TXFrameDrain → W5100 → PHY works.
-echoes the command and never prints `sent` — so the W5100 bus master is stuck
+
-and `TXFrameDrain` is simply waiting on it. Check the ETH_3V3 rail / GC_ON
+⚠️ **OPEN BUG: TX truncates at exactly 16 bytes = the `tx_bytes` FIFO depth.**
-(U12 gates the W5100 rail off GC_ON) before suspecting gateware. Note an
+Past byte 16 the captured frame restarts from its own beginning and mixes in
-earlier contaminated run appeared to transmit at one specific length; that was
+stale bytes from earlier attempts. Cause: `TXFrameDrain` sits in IDLE until it
-leftover state from a previous failed attempt feeding a still-pending drain
+has a LENGTH, and the length only reaches `tx_ctrl` when the NCRA ST bits are
-request — always NCRA-reset between TX attempts when probing.
+written — i.e. *after* the GC has streamed the whole frame. So the entire frame
+has to fit in a 16-deep FIFO, and `BBARegisterFile` silently drops bytes when
+`tx_bytes.w_rdy` is low (SPI cannot back-pressure). Simulation never caught it:
+`TXFrameDrain`'s own tests drive the FIFO signals directly, and the `BBATop`
+test only exercises the W5100→SPRAM→GC **RX** loop.
+Fix direction (needs design + sim, NOT done): make the drain start as soon as
+data is available rather than waiting for the length — e.g. push the length into
+`tx_ctrl` when TWD_HI (0x35) is written, which the GC sets before streaming, so
+the drain consumes concurrently with the EXI writes and the 16-deep FIFO becomes
+a rate-matching buffer instead of whole-frame storage. Alternatively give TX an
+SPRAM ring like RX.
+When probing this, **NCRA-reset between every TX attempt**: a failed attempt
+leaves the drain waiting on a stale length, and later writes feed that pending
+request, which makes an unrelated frame length appear to succeed.
+
+⚠️ **The W5100 can wedge and does NOT recover on FPGA reconfigure.** Symptom:
+the UART shell's own socket-3 `udp unicast` echoes the command and never prints
+`sent`, and any EXI TX then hangs waiting on the bus master. `iceprog -t` does
+not clear it (RST_N floats to its pull-up while the FPGA is unconfigured). A
+12 V power cycle is required. Check ETH_3V3 and GC_ON (U12 gates the W5100 rail
+off GC_ON) before suspecting gateware.
 
 **`id_phase` is a ONE-SHOT.** The device ID is returned for reads of address 0
 only until the first NCRA write with the reset bit, which clears `id_phase`