← AXC-007

Circuit review & bench-test guide

AXC-007 — CP2102N USB-UART console PMOD module

Document purpose#

This document explains the axc-007-console PMOD module at component level and turns the design evidence into a practical manual-review and bench-test plan. It is based on generate_design.py, README.md, and the ERC report in reports/.

This board has never been fabricated. Repository status is schematic generated, ERC clean (0 errors / 0 warnings), netlist reviewed; PCB layout not started; not released. There is no PCB, no BOM export, no DRC record, and no first-article bench result. Every number below is a target to verify against real hardware, not a proven result.

1. What the board does#

The board is the kit console: a Silicon Labs CP2102N USB 2.0 full-speed-to-UART bridge behind a USB-C receptacle, presenting the AruviOS shell over USB at up to 3 Mbaud with RTS/CTS flow control. It is a PMOD Type 3 (UART + flow control) module. Its defining design property is a deliberate no-back-feed architecture: the CP2102N is bus-powered from USB VBUS, its internal regulator produces a 3.3 V VDD that runs the chip and its I/O, and that VDD is isolated from the PMOD 3V3 rail — so no USB 5 V can back-feed the host and no 5 V exists anywhere near the PMOD.

A package subtlety matters: the QFN28 CP2102N has no separate VIO pin (VIO exists only on the QFN32 part). In the datasheet's bus-powered configuration for this package the I/O simply runs at VDD = 3.3 V, which satisfies the module spec's "VIO must be 3.3 V" requirement by construction.

Functional block diagram#

USB-C host                        Module
┌──────────┐  VBUS  ┌──────────────────────────────────────────────┐
│ J2 USB-C ├───┬────│ U1 VREGIN + VBUS-sense  (C1 100n + C2 10µ)    │
│ (UFP)    │   │    │ U1 internal LDO ─> CP_VDD 3.3V (C3 100n+C4 10µ)│
│ CC1 R1   │   │    │           (VDD runs the QFN28 I/O — no VIO pin)│
│ CC2 R2   │   └────│ ── NOT connected to PMOD 3V3 (no back-feed) ──│
│ D+ D- ───┼──> U2 USBLC6-2SC6 ESD ──> U1 D+/D-                     │
│ SHIELD─GND│        │ CP TXD ─R4 100R─> PMOD 3 RXD                 │
└──────────┘        │ CP ~RTS ─R5 100R─> PMOD 1 CTS                 │
                    │ PMOD 2 TXD ─> CP RXD ;  PMOD 4 RTS ─> CP ~CTS │
   PMOD host 3V3 ───┼──> pins 6/12 (host-supplied, UNUSED on-module)│
   PMOD host GND ───┼──> pins 5/11 (common reference)               │
                    │ CP ~RST ─ R3 10k PU to CP_VDD                 │
                    └──────────────────────────────────────────────┘

2. Safety and scope boundaries#

• Everything the PMOD sees is 3.3 V; USB VBUS (5 V) is confined to the VREGIN/VBUS-sense pins, the ESD array, and their decoupling. Hazard to people is negligible.
• THE NO-BACK-FEED RULE — verify it with a meter (critical). The design intent is that CP_VDD is isolated from PMOD 3V3: USB power must never reach the host rail, and the host rail must never power U1. This is the one property that, if a layout or assembly error breaks it, could push 3.3 V (or worse, back-driven current) onto a host rail or tie two supplies together. Before ever connecting the module to an FPGA host, measure resistance between CP_VDD and PMOD 3V3 with a DMM — it must be open (no continuity). Do this on every built board.
• Never assume 5 V tolerance. The UART pins swing at 3.3 V; do not drive them from a 5 V TTL source.
• Standalone USB bench work is USB-bus-powered and self-limiting (the host port supplies VBUS); a normal PC USB port is the test source.
• USB-C here is a UFP (device) with 5.1 k CC pull-downs — it advertises a default-power sink and does not source VBUS. Do not expect PD negotiation.
• ERC-clean is a schematic check only; the D± matched-pair routing and the VDD/3V3 isolation are layout obligations, not proven facts.

3. Power and data sequence#

1. A USB-C cable brings VBUS (5 V) to U1's VREGIN and VBUS-sense pins. The CC1/CC2 5.1 k pull-downs (R1/R2) advertise the UFP so the host applies VBUS. C1/C2 decouple VREGIN.
2. U1's internal LDO produces CP_VDD = 3.3 V (C3/C4 decouple it). On the QFN28 there is no VIO pin, so the UART I/O runs at CP_VDD 3.3 V. CP_VDD connects to nothing but U1's own decoupling and the R3 reset pull-up — it does not touch PMOD 3V3.
3. ~RST idles high via R3 (10 k to CP_VDD), belt-and-braces over the internal pull-up; the device completes reset and enumerates.
4. USB enumeration: the host sees the CP2102N as VID 0x10C4, PID 0xEA60 (Silicon Labs, CP210x), the default identity. A COM/tty port appears; default framing for the console is 115200-8N1.
5. Data direction (host FPGA = DTE): CP2102N TXD carries data toward the FPGA → PMOD pin 3 RXD through R4 (100 Ω). FPGA TXD (PMOD pin 2) drives CP2102N RXD directly. ~RTS (CP) → R5 (100 Ω) → PMOD pin 1 CTS; FPGA RTS (pin 4) → CP2102N ~CTS. Module-driven lines (CP TXD, CP ~RTS) carry the 100 Ω.

4. Interfaces#

There are no dedicated test points; bench probing is at J1 pins, U1 pins, the 100 Ω resistors, and the USB-C shell. CP_VDD-to-3V3 isolation is measured between the CP_VDD decoupling and the PMOD 3V3 pins.

5. Component-by-component review#

5.1 Bridge and USB front end#

5.2 CC pull-downs and reset#

5.3 Flow-control series and decoupling#

Every ref-des is covered: U1, U2, J1, J2, R1–R5, C1–C4.

6. Datasheet summary and design interpretation#

Official references: CP2102N datasheet, USBLC6-2 datasheet, USB4105 drawing. Confirm the default OTP config (VID/PID/baud) is acceptable before procurement — the README flags this as an open item.

7. Expected values before bench testing#

All values are design targets for a board that does not yet exist.

8. Manual schematic and assembly review checklist#

• No-back-feed audit: trace CP_VDD and confirm it reaches only U1's VDD pins, C3/C4, and R3 — and never the PMOD 3V3 net. Trace PMOD 3V3 (pins 6/12) and confirm it is unused on-module.
• Confirm U2 (USBLC6-2SC6) orientation: pin 1 correct, I/O pins on D±, VBUS/GND on the rails.
• Confirm D+/D− are not swapped between J2, U2, and U1, and are a matched pair at layout.
• Verify R1/R2 are 5.1 k CC pull-downs (UFP); R4/R5 sit in the module-driven CP TXD / CP ~RTS paths; FPGA-driven TXD/RTS are direct.
• Confirm C2/C4 are ≥ 4.7 µF on VREGIN/CP_VDD respectively.
• Confirm ~RST pulls up to CP_VDD (not to PMOD 3V3).

9. Ordered bench-test procedure#

Stop at the first abnormal result. Record board serial, chip marking, and host identity.

A. Unpowered inspection and resistance tests#

1. Visual: U1/U2 orientation, USB-C solder, passive bank.
2. DMM: VBUS-to-GND (no short); CC1/CC2 to GND ≈ 5.1 k; RXD/CTS series ≈ 100 Ω.
3. No-back-feed measurement: CP_VDD-to-PMOD-3V3 must read open. If there is any continuity, stop — do not power and do not attach to a host.

B. USB attach and enumeration (no FPGA)#

1. Attach a USB-C cable from a PC. Watch the port: expect enumeration as VID 0x10C4 / PID 0xEA60, a CP210x COM/tty device. Try both cable orientations.
2. Measure CP_VDD ≈ 3.3 V at C3/C4. Confirm no heating.
3. With USB attached but no FPGA host connected, measure PMOD pin 6 (3V3): it must read ~0 V — proving VBUS does not back-feed the host rail. This is the live confirmation of the 8-section no-back-feed audit.

C. Loopback and framing (no FPGA)#

1. Open the CP210x port at 115200-8N1. Jumper PMOD pin 2 (TXD) to pin 3 (RXD) through the module (i.e. loop the host-side data). Type characters and confirm they echo back — proving CP RXD/TXD, R4, and the framing.
2. Sweep baud (e.g. 9600 → 3 Mbaud) and confirm clean loopback; note the highest reliable rate.

D. Flow-control verification#

1. Jumper RTS↔CTS appropriately and drive a flow-control-enabled transfer from the host. Confirm ~RTS/~CTS assert (scope at R5 / CP ~RTS and CP ~CTS) and that the host holds off when flow control is de-asserted.
2. Optionally overrun-test at high baud with and without flow control to show it prevents dropped bytes.

E. ESD-array sanity#

1. Confirm D+/D− idle levels are correct (FS device pulls D+ high through U1's internal pull-up) and that U2 is not loading the lines (enumeration working is the practical proof; a rotated U2 typically breaks it).

F. Host (PMOD) bring-up#

1. Only after the no-back-feed checks pass, plug the module into the FPGA PMOD host. Bring up the AruviOS console: FPGA TXD (pin 2) → CP RXD, CP TXD → R4 → pin 3 RXD. Confirm the shell over USB at 115200.
2. Exercise RTS/CTS from gateware under load.
3. Confirm grounds are common via the PMOD and that the host rail (3V3) and CP_VDD remain independent under all conditions.

10. Troubleshooting map#

11. Bench record template#

12. Review conclusion#

The console is a well-worn design — CP2102N + USB-C UFP + ESD array — but its defining decision is architectural: CP_VDD is isolated from PMOD 3V3, so USB 5 V never back-feeds the host and no 5 V exists near the PMOD. The QFN28's missing VIO pin is not a limitation here; it is what makes the I/O 3.3 V by construction. The two must-do verifications are the meter check that CP_VDD and PMOD 3V3 are truly open (both on the schematic audit and live with USB attached) and the enumeration at VID 0x10C4 / PID 0xEA60, followed by loopback and flow-control. U2's orientation is the easy assembly mistake to catch. Open risks: no PCB exists (D± matching and the VDD/3V3 isolation are layout promises), and the default OTP config (VID/PID/baud) is an unconfirmed README item that must be verified before a board is trusted as the kit console.