Llm kicad

HIL USB-C Control

A bench device that sits between a Raspberry Pi and a USB-C device under test (DUT). Host software gets controlled access to the DUT's USB 2.0 data, USB-C CC attachment and 5 V VBUS, so it can emulate unplugging and reconnecting the DUT without touching its cable.

It is intended for controlled hardware-in-the-loop (HIL) lab rigs. It is not a general-purpose USB-C charger, dock or power-distribution product.

Features

• USB 2.0 high-speed hub with a fixed on-board control interface. The Pi always sees the controller, whether or not a DUT is connected.
• Software-controlled J3 (DUT) state: data, CC/Rp and 5 V VBUS are switched independently.
• Priority power mux: external 5 V on J2 is preferred; J1 (the Pi) is the fallback and is reverse-blocked when J2 is valid.
• J3 VBUS is protected by an eFuse (about 3.6 A typical, below 4.0 A worst case) with over-voltage protection, fault reporting and active discharge.
• Fixed 3 A Rp advertisement on J3. No USB PD, BC1.2, VCONN, SuperSpeed or alternate modes.
• One opto-buffered external control line (J4) and test points for the key rails and signals.
• Controlled via libgpiod on the standard Linux cp210x gpiochip.

Connectors

Architecture

flowchart LR
  J1[J1 USB-C to Pi] -->|D+/D-| H[CH334F USB 2.0 hub]
  J1 -->|VBUS_UP| MUX[TPS2121 priority mux]
  J2[J2 5 V input] -->|VBUS_PWR| MUX
  MUX --> VSYS((VSYS))
  VSYS --> LDO[TLV76733 3.3 V LDO]
  LDO --> H
  H -->|port 1, fixed| C[CP2102N GPIO control]
  H -->|port 2| SW[TS3USB221A data switch]
  SW --> J3[J3 USB-C to DUT]
  LDO --> RP[Rp buffer] --> J3
  VSYS --> EF[TPS259470L eFuse] -->|VBUS_HIL| J3
  C --> EF
  C --> SW
  C --> RP

Board: 4 layers, 50 x 40 mm, top-side SMT, designed for JLCPCB assembly.

Operating cases

J1 and J2 accept regulated 5 V only. Sustained 12 V or 20 V input is outside the product contract.

Software contract

Software owns the state machine. The hardware does not detect DUT attach and does not enforce source capability.

• Disconnect: data off, wait 20 ms, CC off, wait 20 ms, VBUS off, then wait for the discharge confirmation.
• Connect: CC on, VBUS on, confirm VBUS present and no fault, wait 40 ms, data on.

Before a high-current test, confirm that J2 is powering the board. Turn J3 VBUS off before planned J2 removal. The CP2102N GPIO map, configuration image and a control-service example are in architecture/architecture_final.md section 6.

Repository layout

The schematic sheets are 01_power_cc, 02_usb_hub_control, 03_dut_interface and 04_test_validation. Open llm-kicad/llm-kicad.kicad_pro in KiCad 10.

Tools

tools/audit_schematic.py checks symbol pin numbers against placed footprint pad numbers, schematic versus PCB footprint sync, Value text versus the JLCPCB catalogue part, and Datasheet coverage. It exits non-zero if the pin/pad or footprint-sync checks fail.

python3 tools/audit_schematic.py

Known limitations

• Fixed 3 A Rp: the advertisement can exceed the active source's real capacity.
• No hardware DUT-attach detection: an unplugged DUT can leave J3 VBUS live until software disables it.
• A single priority mux is the only isolation between J1 and J2. It is not an independent-source isolator, and a split cable that joins an external supply to the Pi is not protected against.
• No per-input current limit or input over-voltage disconnect.

The full list and the release acceptance checks are in product_description.md sections 7 to 9.

Status

Hardware revision V2.0. Five units are built, identified 1-5, each programmed with the CP2102N configuration image carrying Release Version 2.00 (0x0200) — the host reads this back as bcdDevice = 0x0200, though only after the board has been power-cycled. All five units were verified 2026-10-14: correct configuration image and power-up safe state, VBUS rising in 18–21 ms, and a USB mass-storage DUT enumerating at J3 on connect and dropping off on disconnect. Per-unit evidence is in code/fleet-record.tsv. The unit ID is carried in the CP2102N USB serial descriptor (0001-0005); the manufacturer and product strings stay at the Silicon Labs defaults, so the serial descriptor is what distinguishes one unit from another. See architecture/architecture_final.md section 6.3 for the Release Version and serial-number policies and the per-unit read-back gate.

Before release, see the open items in the schematic review report and the mandatory prototype tests in architecture/architecture_final.md section 10. The CP2102N must be programmed with the configuration image before use.