EXI bring-up: full Swiss init runs on hardware; W5100 TX blocked

The whole GC init sequence now runs over EXI on the real board: device ID,
NCRA reset self-clear, PAR0-5, MAR, ANALOG, NWAYC, IMR, NCRA SR, NWAYS 0x17.

GC->wire TX does not complete.  Not an EXI fault and not tx_bytes depth --
8-byte frames fail too, and the UART shell's own UDP send hangs the same way,
so the W5100 bus master is stuck and TXFrameDrain is waiting on it.

Also records that id_phase is a one-shot cleared by the first NCRA reset, so
a re-run probe reads 00 00 00 00 for the device ID and looks broken.

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

CLAUDE.md

@@ -272,6 +272,30 @@ device and exercised the register file end-to-end:
 | IMR @0x08 write `0x86` + readback | `0x86` |
 | NCRA @0x00 write `0x01` (reset) | self-cleared to `0x00` on the first poll |
 
+**The full Swiss init sequence runs on hardware (2026-09-30)**, driven from the
+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.**
+Setting the NCRA ST bits never produces TI, and NCRA keeps reading back `0x0a`
+(ST never clears), for EVERY frame length 8…60 with a full NCRA reset between
+attempts. The cause is NOT the EXI side and NOT `tx_bytes` depth (8-byte frames
+fail too): the **UART shell's own socket-3 `udp unicast` also hangs** — it
+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
+(U12 gates the W5100 rail off GC_ON) before suspecting gateware. Note an
+earlier contaminated run appeared to transmit at one specific length; that was
+leftover state from a previous failed attempt feeding a still-pending drain
+request — always NCRA-reset between TX attempts when probing.
+
+**`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`
+permanently (`bba_register_file.py:330`); after that address 0 reads back NCRA.
+This is correct — it matches the GC's init order — but it means a re-run of any
+probe that already issued an NCRA reset will read `00 00 00 00` for the device
+ID and look broken. Reconfigure the FPGA (`iceprog -t` is enough) to restore it.
+
 Two bring-up gotchas, both cost real debugging time:
 - **The master must sample MISO during the CLK-LOW phase.** The FPGA drives MISO
   on the RISING edge (Mode 3), so sampling just after that edge races the