Works the TPS25961 fix out from the datasheet rather than from memory, and
re-solves it against resistors already on the BOM.
OVLO: TI's 3-resistor ladder (eq 7/8) -> R46 620k->150k, R47 100k->10k, new
R48 12k + R49 2.2k (=14.2k). UVLO 8.93 V typ, unchanged from today; OVLO
15.21 V typ, 15.81 V worst case. The OVLO ceiling is set by U3 (TPS562201,
4.5-17 V input), not by the eFuse -- that rules out a tempting 3-resistor
solution tripping at 17.24 V.
ILIM: R45 100k -> 33k. 0.516 A sat BELOW the board's own 621 mA inrush, so
the part entered current limiting on every power-on (-> thermal shutdown ->
retries -> latch-off). Inrush control comes from the fixed 5.17 V/ms slew
rate, not ILIM, so raising ILIM costs no inrush protection; it is pure fault
protection at ~27x the measured 56 mA load.
Every value is already stocked and 620k loses its only user: one FEWER unique
part, +2 placements.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The PC's replies are unicast to our own MAC, which it could only learn from
our requests, so the loop is closed independently of any packet capture.
Records the four W5100 fixes it took and the caveat that TI does not mean the
chip transmitted.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RX_RSR_CHK returned to IDLE when RSR==0 without clearing Sn_IR. SEND_OK
(bit 4) fires after every successful transmit and the RX path only ever
cleared RECV (bit 2), so INT_N stayed asserted; because IDLE tests
~w5100_int_n BEFORE tx_valid, the FSM span IDLE->RX_CHECK->RX_RSR_CHK->IDLE
and TX was starved permanently. Observed on hardware as the first frame
transmitting and every later one never setting TI while RX kept working.
Now clears every Sn_IR bit except RECV, so a frame arriving between the RSR
read and the write still raises INT_N and is served next pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
w5100_rst_n was declared and never driven anywhere -- the pin sat at its init
value of 1 forever. The only reset the chip ever got was the MR software
reset, which arrives over the very bus a wedged chip has stopped answering, so
a wedged W5100 could not be recovered at all: not by NCRA reset, not by
reflashing, not even by reconfiguring the FPGA (RSTn just floats to its R36
pull-up while unconfigured). Only a 12 V power cycle worked.
Init now pulses RSTn low (1 ms, datasheet minimum is ~2 us) and waits the full
post-reset settle before touching the bus. RSTn low time is clamped to
reset_cycles so the testbenches' small values stay reachable by wait_ctr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The init does MR=0x80 (software reset) then waits reset_cycles before writing
NETLCKR/SHAR/SIPR/socket registers. That wait was 24_000 cycles = 1 ms at
24 MHz, but the W5100S needs the datasheet's 60.3 ms -- our own bus self-test
needed ~85 ms before the chip answered at all.
1 ms is marginal rather than simply wrong, which is why this presented as
intermittent: an NCRA reset sometimes left the chip still resetting while the
init writes landed on it and were silently dropped, leaving it misconfigured
and the bus master blocked. Symptom was a W5100 that wedged after an NCRA
reset -- TX never completing and the UART shell's own 'udp unicast' hanging --
recoverable only by a 12 V power cycle. Note RST_N is never asserted by the
gateware; only the software reset is used, so this wait is the only settle
time the chip gets.
Default is now 2_000_000 = 83 ms. Testbenches pass small values explicitly and
are unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TX: the TWD fix lands a full 60-byte ARP on the wire, byte-for-byte correct
(previously truncated at 16). TI sets.
RX: a real 342-byte DHCP broadcast from the PC was received in MACRAW mode,
assembled into the SPRAM ring and DMA-read back over EXI. The descriptor
length 0x015A cross-checks exactly against the frame's own IP total-length
field plus the ethernet header, so the assembler's length is confirmed, not
merely plausible.
Also replaces the full-path probe's 'is 08 and 06 somewhere in the buffer'
guess with a real descriptor decode -- it called a DHCP frame an ARP reply.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TXFrameDrain sat in IDLE until it had a length, and the length only reached
tx_ctrl when the NCRA ST bits were written -- after the GC had streamed the
whole frame. So the entire frame had to fit in the 16-deep tx_bytes FIFO, and
BBARegisterFile silently drops bytes when w_rdy is low (SPI cannot
back-pressure). On hardware this truncated frames at exactly 16 bytes: a
captured ARP had 16 correct bytes followed by the frame restarting over itself.
The length is now handed to the drain one cycle after the TWD_HI (0x35) write,
which the GC issues BEFORE streaming data. The drain starts early and blocks
on tx_bytes_r_rdy, consuming bytes as they arrive, so tx_bytes becomes a
rate-matching buffer instead of whole-frame storage. The ST write remains a
fallback trigger for software that skips TWD, guarded by tx_queued so one frame
is never queued twice.
Adds BBATop T8: streams a 34-byte frame (> the 16-deep FIFO) over EXI and
checks the W5100 model received it byte-for-byte. Verified to FAIL without the
fix with exactly the hardware symptom -- 16/34 bytes, first bad byte at index
16. The gap that let this ship: TXFrameDrain's own tests drive the FIFO
signals directly, and the BBATop test only covered the RX loop.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
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>
First silicon proof of the EXI capture path. A Pi bit-banging EXI into J4
reads the device ID 04 02 02 00 21/21, NWAYS 0x17, HIPR 0x01, writes and reads
back PAR0-3, writes IMR, and sees NCRA's reset bit self-clear.
Fixes two host-side bugs found getting there:
- exi_devid_rpi.py sampled MISO just after the rising edge, racing the slave's
own update and landing one bit early (04 came back as 08). Sample in the
CLK-low phase, as the simulation does.
- pi-exi-wirecheck.py's bridge scan drove HIGH against pull-downs, but the
FPGA's SB_IO pull-up out-pulls the Pi's internal pull-down, so every pin
reported as bridged. The aggressor now drives LOW against pull-ups.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verifies the harness before attempting a real EXI transfer. Keyed on the
EXI_J4 build's SB_IO pull-ups: an FPGA input with PULLUP=1 reads HIGH when
connected, follows the Pi's pull when open, and reads a hard 0 only when
shorted -- so all three cases are distinguishable from the Pi alone.
Includes a T0 control on known-unwired pins; without it a broken pull
mechanism would turn every 'connected' verdict into a false pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Factors the EXI_J4 pad merge out of synth.py so the synthesis path and the
test exercise the same code. Verifies the device ID (04 02 02 00) enumerates
over SP1 with J4 idle, over J4 with SP1 idle, and over SP1 again afterwards,
plus a register read via J4 and the full cs_n truth table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4/8 seeds pass capture, best seed 8 = 63.09 MHz (+17% margin) — same pass
rate as the default build, so the AND-merge costs no measurable timing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lets a bench host drive EXI without the SP1 edge connector, for bring-up.
Merges a second set of EXI pads onto the existing ones rather than repinning,
so the SP1 connector stays live and the default build is untouched. The three
inputs are AND-merged, which is correct because every EXI input is inactive
HIGH (CPOL=1 clk, active-low cs_n, mosi only matters while cs_n is low): the
unplugged side idles at 1 through its SB_IO PULLUP and passes the other side
through, so no select signal is needed. Outputs drive both pads.
All five J4 pads are on the same bottom die edge as the EXI pads (x=13..18 vs
x=5..9), so the capture domain keeps its anchor. It still adds 3 LUTs ahead of
the input synchronisers, so EXI_J4 builds must sweep seeds.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Anode-side pad at 3V3, cathode at 0V, LED dark — the full rail standing
across it means no current and no drop across R42, so Q2 and R42 are both
doing their job. Probe pressure on the anode pad lights it at full
brightness: the terminal is sitting on the pad unwetted. Reflow fixes it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The W5100S ethernet back-end now works end-to-end on real hardware: a complete,
correctly-checksummed UDP datagram (10.0.0.99:40000 -> 10.0.0.50:6464, 32-byte
payload) was transmitted by the FPGA-driven W5100S and captured on a PC, after a
full bidirectional ARP handshake.
Records the three W5100S-specific findings in CLAUDE.md (NETLCKR unlock, the
15-bit IDM address space putting the buffers at 0x4000/0x6000, and the 60.3 ms
reset-to-ready time), and notes that UDP unicast is the reliable bring-up path
while a 255.255.255.255 send sets SEND_OK without appearing on the wire.
w5100_udptest.py is the self-contained configure+send+readback probe that
isolated all of this.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reverts the 0x8000/0xC000 change from 162dbf7, which was WRONG and actively
broke transmission. The W5100S datasheet pseudo-code quotes 0x8000 (TX) /
0xC000 (RX) for the memory blocks, but the PARALLEL/indirect (IDM) interface
only decodes a 15-bit offset. Bench-proven with an address-aliasing probe:
writing distinct values to each candidate base and reading them back showed
0xC000 and 0x4000 are the SAME cell (0xC000 & 0x7FFF == 0x4000) while 0x6000
holds its own value.
Consequence of the bad base: every payload byte written to 0x9800+i aliased
down onto 0x0000+i, landing on SHAR (0x09-0x0E) and SIPR (0x0F-0x12) and
overwriting them with the payload. The chip then transmitted frames with a
garbage source MAC/IP, which the peer NIC drops without counting -- the
"SEND_OK but rx_packets=0" symptom, and the bogus SIPR0 readback (0x50 was
literally payload byte 15, 'P').
The NETLCKR unlock from 9c4bc7a is a genuine W5100S requirement and stays.
Also:
- w5100_udptest.py: self-contained configure+send+readback probe (and the
address-aliasing probe that found this), reports over UART.
- scripts/build-flash.sh: sweep N seeds and flash the best (capture timing is
seed-dependent, so the sweep is mandatory).
- scripts/uart-console.py: interactive UART console, plus --send/--read
one-shot modes for scripting.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reads socket-3 / status registers over the indirect bus and streams them on the
UART, without resetting the chip, to inspect what a UDP send left behind. First
hardware run was inconclusive (socket regs read 0x00 but SIPR/PHYSR didn't match
either "state persisted" or "clean reset") -- the FPGA reflash appears to glitch
RST_N, so a self-contained configure+send+readback is the reliable next step.
Committed as a starting point for that.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Second W5100S-vs-W5100 gotcha found at bring-up: the W5100S has a Network Lock
Register (NETLCKR, 0x0071) the original W5100 lacks. It defaults to 0x00 (locked),
and while locked, ALL writes to GWR/SUBR/SHAR/SIPR are silently dropped -- so the
chip has no source IP/MAC and the UDP/MACRAW send builds nothing (chip reports
SEND_OK but transmits nothing; socket registers aren't locked, which is why an
indirect write/readback of Sn_PORT succeeded). Fix: write the unlock value 0x3A
to NETLCKR right after MR enables indirect mode, before the network-config writes.
On the bench this flipped the board from silent to actually keying frames onto
the wire (magjack activity LED now blinks).
Also:
- bba_top.py test model: RX buffer base 0x6000 -> 0xC000 to match the W5100S
buffer-base fix (the model hardcoded the old W5100 address).
- w5100_selftest.py: added an indirect-mode (IDM) write/readback probe of a
socket register + IND= field in the UART report, to isolate direct-vs-indirect
access (confirmed indirect works on the real chip).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
From the physical V2 bring-up session (2026-09-20):
- exi_bba/w5100_selftest.py (NEW): standalone FPGA<->W5100 bus diagnostic.
Clock-independent data-bus walk (direct-mode GAR0 read-back, all 8 lines) +
MR software-reset self-clear (needs the 25 MHz crystal). Reports 4 verdicts on
D6/D7 LEDs AND over UART (115200): GOOD / data-line-N / clock-dead / no-response.
Boot wait is 85 ms (> the W5100S 60.3 ms init). On this board: GOOD -- bus +
all 8 data lines + 25 MHz clock all verified (unlike V1's broken D3).
- REVIEW.md / TODO.md: eFuse U13 OVLO is tied to GND, which on the TPS25961
selects the internal FIXED ~6 V overvoltage cutoff -- so it blocks the 12 V
rail entirely (bench-confirmed: 12V_EXI=0, GC_ON=0, W5100 unpowered). FAB-
BLOCKER for V2.1: fix with an OVLO divider (~1.1M/100k -> trip ~15 V). Bench
workaround: lift U13 pin 2 (OVLO) off GND. Also closed the eFuse-placement,
GND-via/3V3-zone, and CC-ESD TODO items.
- hardware/re-bba-rb/exi_devid_spi.py (NEW): Pi hardware-SPI (~25 MHz) EXI
device-ID host, companion to the bit-bang exi_devid_rpi.py.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The W5100ParallelMaster used the original W5100's TX (0x4000) / RX (0x6000)
memory-block base addresses. This board's chip is a W5100S, whose TX/RX memory
blocks live at 0x8000 / 0xC000 (datasheet: TX 0x8000-0xBFFF, RX 0xC000-0xFFFF).
Consequence found at hardware bring-up (2026-09-20): every frame was written to
dead address space, so SEND transmitted the (empty) real TX buffer -- the chip
reported "sent" but nothing valid reached the wire (peer rx_packets stayed 0,
link up). The sim bus-model used these same constants, so it never caught it --
exactly the "register addresses are datasheet-from-memory, confirm at bring-up"
risk. All socket register offsets were verified correct against the W5100S
datasheet; only the two memory bases were wrong. Fixes both the socket-N UDP
test and the socket-0 MACRAW (GC) path.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Hardware bring-up correction (Dennis, 2026-08-22): writing the FT2232H product
string to the undersized 93LC46B (U7) does NOT harmlessly fail — the partial,
mirrored write lands a checksum-valid-but-garbage config, and the FT2232H then
FAILS USB enumeration entirely (dead silent, no dmesg attach). It does NOT fall
back to ROM defaults; only a blank/checksum-invalid EEPROM does. The earlier
claim that "a bad EEPROM always falls back and still enumerates" was WRONG.
Recovery (confirmed working): power on with U7 CLK shorted to GND so the FT2232H
can't read a valid config -> forces ROM defaults -> enumerates -> then erase U7.
Updated REVIEW.md, TODO.md, the flash-re-bba-rb skill (do-not-program warning +
recovery, native-Linux troubleshooting), and flash_ftdi_eeprom.py comments/help
to state the soft-brick reality. The script already refuses the write on
mirroring detection; --force now documented as "reproduce the soft-brick".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Devcontainer now grants libusb access to the FT2232H so iceprog (bitstream) and
pyftdi (FT2232H EEPROM) run inside the container:
- devcontainer.json: --privileged + /dev/bus/usb bind mount
- Dockerfile: sudo (NOPASSWD for vscode; USB nodes are root-owned), libusb-1.0-0,
libftdi1-2, pyftdi
Add the flash-re-bba-rb skill documenting the procedure (bitstream via best swept
seed, optional EEPROM string, troubleshooting, guardrails) and
flash_ftdi_eeprom.py (pyftdi, backup-first, dry-run default) + ftdi_eeprom.conf
value spec.
Bring-up on the repaired V1 unit: bitstream flash VERIFY OK (iceprog
build/seed4/top.bin, capture 58.36 MHz). EEPROM product string CANNOT be
programmed on V1 — U7 is a 93LC46B (128 B), too small for the FT2232H, which
needs a 93LC56B (256 B); the 128 B chip mirrors and the config write fails
verify. This overturns the old REVIEW note "93LC46B = correct for FT2232H"
(that only checked ORG, not size). Board still works blank -> ROM defaults;
iceprog + UART unaffected. Documented in REVIEW.md + TODO.md (swap U7->93LC56B
for V2); flash_ftdi_eeprom.py detects the mirroring and refuses the write.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Board V1 ships as-is (capture closes full-speed on 4/8 seeds). Documents,
for a possible future push toward more capture margin (e.g. 64 MHz), that
the binding path is now the tx_fifo exi->capture Gray-code CDC pointer
loop (~6.4ns logic + ~10.7ns routing = 17.1ns / 58.4MHz), and the two
measured levers: a lightweight 2-deep ping-pong TX CDC (RTL, pinout-
independent, est. 67-80MHz - the reliable one) and EXI/W5100 pin
co-location on one die edge (respin, routing-half only, ~63MHz seen).
Both investigated but NOT applied.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
An interactive UART command shell drives a UDP send/receive test on the
W5100's socket 3, running ALONGSIDE the live BBA (socket-0 MACRAW) with
EXI keeping bus priority. MACRAW+UDP coexistence is W5100S-datasheet
confirmed (S4.6 + "4 independent SOCKETs"). Now the default flash build
(--console selects the old event-log console).
New / changed gateware:
- uart_shell.py (new): rebbarb> shell over FT2232H channel B. Commands:
help; udp unicast <ip> [msg]; udp broadcast [msg]. After each send it
waits (bounded, else "timeout") for a reply and prints "rx <payload>".
Line buffer + message ROM live in block RAM with a sequential parser
(LC-efficient); 1-deep RX holding reg keeps pastes intact. 8 sim tests.
- w5100_parallel_master.py: configurable UDP socket (default 3) with UDP
send AND receive (IP-stack init, runtime dest IP, WIZnet UDP RX header
+ payload). Gated by enable_udp_test so the MACRAW path is unchanged
when off. Tests U1-U4 + MACRAW T1-T5.
- exi_capture.py: CAPTURE-DOMAIN CRITICAL-PATH FIX. The TX byte-FIFO
read-enable was gated by its own gray-coded ready
(r_en = ... | (flushing & r_rdy)), forming a consume_ptr -> gray ->
r_rdy -> flush -> r_en -> consume_ptr loop that capped capture_clk.
Replaced the r_rdy-based "drain until empty" flush with a fixed-length
drain counter (FIFO is only tx_depth deep), removing the pointer
feedback from r_en. Path 24.3 -> 19.6 ns; flush behavior preserved.
- bba_top.py: wire shell <-> W5100 UDP (send + rx); shell additive.
- synth.py: shell default build; env-var UDP network config; documents a
reverted PNR-timing-priority experiment.
Timing (--seeds 8, default shell build, 67% LC): capture closes on 4/8
seeds (best seed 4 = 58.36 MHz, +8%), clk passes on all. This is BETTER
than the pre-shell 2/8 baseline because the flush fix improved the
capture domain intrinsically. Flash build/seed4/top.bin.
Bring-up caveats (unchanged): W5100 socket register addresses / UDP
header format are datasheet-derived (confirm on hardware); UDP_SRC_IP /
subnet / gateway must match the LAN for unicast ARP.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
All eFuse/RExt/EE-CS parts (U13, R43-R47, C66, R44, D13) are picked with
MPN+LCSC in the live BOM and placed+routed on the PCB - the TODO/REVIEW
notes calling their fields 'intentionally blank' were written when the
parts were first added and never updated. Corrected to reflect the
committed state.
Also documents the kicad-cli DRC gotcha that caused a false alarm: it
does not refill zones, so it reports phantom GND-via-in-3V3-pour and
thermal-pad clearance errors (actual 0.000mm) on a board the GUI reports
clean. Added a warning at the top of TODO and in REVIEW section 7 so no
future session mistakes it for a real defect.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Documents everything examined in the 2026-07-17/18 review - not just
findings but full coverage with verdicts, so future sessions know what
not to re-review: per-sheet verification against datasheets and the
WIZnet reference design, the settled look-wrong-but-correct list
(VPHY/VPLL on 3.3V, D4/D5 floating VBUS + flow-through, EN at 12V,
RSET 12.4k, no CT cap, DO/DI direction evidence), PCB/JLC/BOM audit
state, explicit not-reviewed list (bench/gateware items), and a binding
rule to keep the file updated in the same commit as any change to a
reviewed circuit. Referenced from CLAUDE.md alongside TODO.md.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Schematic fixes (PCB placement/routing of new parts pending, F8 lists them):
- FTDI rewired to stock iceprog convention: FLASH_CS ADBUS3->ADBUS4,
CDONE ACBUS1->ADBUS6, CRESET ACBUS0->ADBUS7 (old pins NC). With a
blank 93LC46B (default 0403:6010) stock iceprog now works unmodified;
EEPROM workflow decided: ship blank, FT_PROG optional (keep VID/PID).
- TPS2116 PR1 divider: R3 200k->150k (C25755) - switchover now at
2.30-2.70V worst case instead of 20mV under the 3.3V rail.
- ETH_RST: R36 10k pull-up to ETH_3V3 (RSTn floats during FPGA config).
- Debug provisions: D6 green heartbeat LED (C72043) on FPGA pin 47,
D7 red EXI-activity LED (C2286) on pin 48, 330R C25104 series; J4
6-pin LA header (GND + DBG0-4 = pins 9/10/11/12/6, unpopulated);
TP1-TP5 test points (3V3/1V2/ETH_3V3/GC_ON/GND, in_bom no); FID1-3
fiducials placed board-only on the PCB, track-clearance checked.
- Embedded Device:LED / Connector:TestPoint / Conn_01x06 lib symbols.
Closed by analysis (no change): TPS22810 CT cap unnecessary (DS Table 2:
~98us rise at 3.3V with CT=0 -> ~0.5A inrush); RSET_BG 12.4k accepted
(12.3k is E192; WIZnet ref synthesizes it as 12k+300R; 0.8% immaterial).
Verified: ERC 0; netlist 132 vs BOM 125 differing only by the 7
deliberate in_bom=no items (J3, J4, TP1-5); LED polarity and TP rails
confirmed in netlist; PCB DRC 0 errors with fiducials placed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Re-verified every open item against the current board:
- All three critical findings (DO/DI swap, MDI termination incl.
dampers + center-tap bypass, FTDI EEPROM resistors) now done in both
schematic and PCB - marked resolved with review results
- Marked verified-done: 12V cap ratings, 1% tolerances, .history
ignore, fiducial check (absent - to add with debug pass)
- Confirmed still open: ETH_RST pull-up, PR1 divider margin (R3 still
200k), RSET 12.4k vs 12.3k, TPS22810 CT, iceprog pin mapping, board
PCF, debug LEDs/test points, mechanical fit, ordering options
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Insertion by Dennis; reviewed:
- DRC 0 errors / 0 unconnected / 0 schematic parity
- R32-R35 sit in-line between the termination cluster and D4/D5, each
aligned to its own line row; MDI_* stubs only 1.45-1.48mm, no new
vias, all pair copper at the ETH_DP 0.2mm width
- Pair skew after insertion: TX 0.66mm, RX 1.81mm - both far inside
the 100BASE-TX budget
- C20/C21 placed against J2's pin column, about as close as the In1
plane void allows while keeping short GND vias
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Completes the WIZnet reference schematic for the MDI section:
- R32-R35 3.3R 1% (YAGEO RC0402FR-073R3L, LCSC C137986) in series in
each MDI line per WIZnet note 6 (EMI damping). Chain per line is now
U11 pin -> 49.9R termination tap -> 3.3R -> D4/D5 flow-through -> J2.
Chip-side nets keep PHY_*; the D4/D5-side segments are renamed MDI_*
and added to the ETH_DP netclass patterns so the impedance DRC rules
police both halves.
- C20 100nF (C1525) + C21 1uF (C15849) on ETH_3V3 per WIZnet note 7 -
to be placed AT J2 pins 4/5 tapping the In2 ETH_3V3 island.
(Also carries KiCad's resave/reposition of ethernet.kicad_sch from the
rework session - netlist-identical, verified.)
Verified: ERC 0, netlist 121 components vs BOM 120 (J3-only delta),
PHY_TX_P = {U11.3, R26.1, R32.1}, MDI_TX_P = {R32.2, D4.1}, and
likewise for all four lines. PCB: 6 footprints to place (cut the lines
between termination and D4/D5 for R32-R35; C20/C21 at the jack).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Record the verdict so it isn't relitigated: USBLC6 is ST-rated for
Ethernet, PHY-side placement is standard practice, floating VBUS is
deliberate (3.3V-biased lines would clip against a tied rail), and the
split PHY_*/ETH_* nets force zero-stub flow-through routing - the
better ESD topology. Earlier stub/DNP suggestion withdrawn.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The 93LC46B's DO and DI were both tied directly to EEDATA, causing
drive contention during EEPROM read turnaround. Per the FT2232H
datasheet ("Connect directly to Data-In of the EEPROM and to Data-Out
of the EEPROM via a 2.2K resistor. Also, pull Data-Out of the EEPROM
to VCC via a 10K resistor"):
- U7.4 (DO) moved onto new net EE_DO
- R30 2.2k (UNI-ROYAL 0402WGF2201TCE, LCSC C25879, Basic) between
EE_DO and EE_DATA
- R31 10k (0402WGF1002TCE, C25744) pull-up from EE_DO to 3V3
- EEDATA -> DI (U7.3) stays direct
Schematic only; R30/R31 still need placing near U7 in the PCB rework.
Verified: ERC 0, EE_DATA = {U8.61, U7.3, R30.2}, EE_DO = {U7.4, R30.1,
R31.2}, R31.1 on global /Power/3V3 (no orphan local net), netlist
115 vs BOM 114 differing only by the deliberate J3 exclusion.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The BOM was already fully populated (112/113 parts with MPN+LCSC) - this
audits it against the hardware-review requirements and closes the gaps:
- J3 (SP1 edge connector) set to in_bom=no: it is PCB gold fingers, not
a purchasable part. Netlist-vs-BOM count check now differs by exactly
this one deliberate exclusion.
- Crystals verified CL=12pF (Y1 C70565, Y2 C9006, both JLC Basic) -
matches the 18pF load caps and W5100S Table 9. TODO item closed.
- 12V-rail caps verified >=25V (C3/C4 25V, C6 50V, C65 Lelon 25V SMD
electrolytic); divider/REF/RSET resistors verified 1%.
- Noted: D2 LCSC C49383400 is the ElecSuper PUSB3AB6Z(ES) clone of the
Nexperia part (same DFN-7 package, 0.15pF) - pin-compatible.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Per the WIZnet W5100S reference schematic (note 4: "to avoid the 100M
overshoot, place the 49.9 resistors and 0.1uF capacitor near the MDI
pin"): R26/R27 (49.9R 1%) from TXOP/TXON to a common node bypassed by
C18 (100nF) to GND, and R28/R29 + C19 likewise for RXIP/RXIN. Attached
on the PHY-side nets (chip side of D4/D5). BOM fields populated
(UNI-ROYAL 0402WGF4999TCE / LCSC C25120, Samsung CL05B104KO5NNNC /
C1525). Optional 3.3R series dampers deliberately omitted.
Schematic only - the 6 footprints still need placing/routing next to
U11 pins 2/3/5/6 (Update PCB from Schematic). DRC parity reports
exactly those 6 missing footprints and nothing else.
Verified: ERC 0, netlist 107->113 components, termination nets match
the reference topology.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
SP1 DO/DI naming is console-perspective (verified against SD Gecko and
SD2SP2 wiring): pin 6 DO = GC data out = adapter MOSI input, pin 9 DI =
GC data in = adapter MISO output. The design doc's SP1 table had the
roles reversed and the schematic followed it, putting the FPGA's MISO
driver on the GC-driven DO line (bus contention).
Fix keeps all PCB routing identical:
- Swap net names EXI_MOSI(_RAW) <-> EXI_MISO(_RAW) across exi/Fpga/root
sheets and the PCB (also renames the D2 PUSB3AB6 channel assignments).
- Swap R21 (22R) <-> R25 (33R) identities between the two footprint
positions so 33R stays on the FPGA-driven MISO line, 22R on the MOSI
input.
- Correct the SP1 pin table + MISO-tristate note in
docs/gc_bba_fpga_design.md (root cause).
Resulting board pin map (for the future board PCF): EXI_MOSI = FPGA
pin 4 (IOB_8a, input), EXI_MISO = pin 3 (IOB_9b, output).
Verified: ERC 0, DRC 0 errors with schematic parity 0, netlist shows
J3.6(DO)->R21->pin 4 and J3.9(DI)->R25->pin 3.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Remove stale lowercase power.kicad_sch (pre-rework draft; live sheet is
Power.kicad_sch). Both paths were git-tracked, which on a case-insensitive
Windows checkout makes them one file on disk - deleting the stale one also
deleted the live one, and restoring the live sheet resurrected the stale
path at the next commit. Removing the path from the index breaks the loop.
- Remove re-bba-rb.kicad_pcb.old.* leftovers (recoverable from history).
- Restore hardware/re-bba-rb/datasheets/ (deleted accidentally by 3547302)
and add the two missing datasheets: TPS22810 (power) and PUSB3AB6 (exi).
- Add hardware/re-bba-rb/TODO.md capturing the 2026-07-17 review findings
(EXI DO/DI swap, missing W5100S MDI termination, FTDI EEPROM resistors,
iceprog pin mismatch, PR1 margin, BOM/ordering notes); referenced from
CLAUDE.md.
Verified after cleanup: ERC 0 violations, netlist identical (107 components).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Store datasheets for the parts actually placed in the current design,
grouped under hardware/re-bba-rb/datasheets/ by sheet (fpga, power,
usb, ethernet). Filenames normalised to the part MPN. All tracked
through git-lfs per .gitattributes (*.pdf).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Roflin
Dennis Brentjes