USB-C Power Hub Design
Worked for 4 mins 49 sec
Assigned validated manufacturer names and MPNs to every requested capacitor, resistor, and L2 without changing connectivity or placement.
Open item
- The three “Missing Power” errors remain false positives: the STUSB control outputs are incorrectly typed as power inputs in their library symbols. The actual pull-up, NPN inverter, and eFuse-enable circuits are correct, and the available project editing controls cannot safely correct individual terminal types.
No new ERC errors were introduced.
Start Auto-Layout
Thought for 6 sec
I’ll inspect the board state and determine whether placement, routing, or both are required. I’ll apply the needed auto-layout steps, then verify airwires, overlaps, component containment, and DRC.
Worked for 11 mins 3 sec
PCB inspection completed:
- Current board is the default 160 × 100 mm, 4-layer layout.
- All 83 components are placed, but placement is scattered and partially routed.
- Both replacement and routing are needed; existing partial traces may become stale after replacement.
- Recommended direction: resize to approximately 50 × 80 mm or 80 × 80 mm, place the three USB-C receptacles at accessible edges, regroup the power/PD sections, then reroute and run DRC.
No layout changes were applied because available ACUs were exhausted during execution.
Configure 80mm board
Choose compact layout
Review PCB DRC
Refine this doc
Ask about this doc
Project Specification
Project Overview
First-pass schematic for a USB-C PD power-distribution hub. Status: Draft / engineering review required.
Intended Use
One upstream USB-C PD supply powers a Raspberry Pi 5 and a USB-C display through two independently negotiated downstream source ports.
What the Device Should Do
- Negotiate an upstream target of 20 V/5 A (100 W), requiring an e-marked 5 A cable.
- Port A advertises 5.1 V at up to 5 A (27 W class) for Raspberry Pi 5; require a 5 A e-marked cable for >3 A.
- Port B advertises SPR fixed PDOs 5, 9, 12, 15, and 20 V, capped at 3 A and 60 W.
- Dynamically allocate and shed load so output power plus losses and controls remain within the active upstream contract.
- Never claim both outputs can exceed the negotiated upstream budget.
Main Features
Independent downstream PD negotiation; input/output protection; current sensing; programmable display rail; dedicated high-current Pi buck; firmware-controlled policy and fault handling.
System Architecture
See the Block Diagram project file.
Hardware Subsystems
- Upstream Type-C receptacle, ESD/TVS, fuse/eFuse, sink PD controller and protected 20 V bus.
- Port A 20 V-to-5.1 V >=5 A buck, source switch, current sense, discharge, Type-C source controller and receptacle.
- Port B programmable buck/buck-boost, source switch, current sense, discharge, Type-C source/DRP controller and receptacle.
- MCU/policy controller with controller buses, telemetry, enables, interrupts and fault inputs.
- Auxiliary logic supply and decoupling.
Interfaces and Connections
USB-C CC1/CC2 and VBUS on all ports; controller-to-MCU I2C/SPI/GPIO as supported by selected parts; analog/current telemetry; firmware-controlled converter setpoint and source-enable signals.
Power and Runtime Expectations
Externally powered; no battery. Full-load operation assumes a valid 100 W upstream contract and 5 A cable.
Power Tree and Power Budget
At 90% conservative conversion efficiency: Pi input allocation 25.5/0.90 = 28.33 W; display input allocation 60/0.90 = 66.67 W; controls = 2 W; total = 97.0 W. Margin at 100 W is only 3.0 W. Firmware must reserve margin and reduce/deny Port B allocation when the upstream contract is lower or measured input approaches limits.
Manufacturing and Assembly Expectations
Production-intent SMD architecture. High-current/thermal layout, connector current rating, eFuse SOA, converter thermals, and USB PD compliance require later PCB and qualified review. PCB layout is explicitly out of scope for this pass.
Firmware-Relevant Hardware Requirements
Firmware reads active upstream contract and telemetry, programs downstream PDO availability, sequences converters and source switches, enforces cable-current limits, handles faults/discharge, and performs deterministic load shedding with Pi priority.
Physical Design Expectations
Connectors accessible at board edges; high-current paths short; separate noisy converter regions; thermal copper and airflow to be determined during layout.
Important Design Decisions
Port A has priority and is dedicated to Pi 5. Port B allocation is dynamic. A controller-plus-MCU architecture is acceptable if an autonomous multi-port power-sharing controller is unavailable.
Assumptions
Upstream source supports 20 V/5 A; cables claiming 5 A are electronically marked; display accepts at least one advertised fixed PDO; no USB data routing is required.
Change Notes
Initial requirements and conservative power budget captured.
First-pass schematic instantiated with three real GCT USB4105-GF-A 5 A receptacles, STUSB4500 sink control, dual STUSB4710 source controllers, STM32G071 policy MCU, protected VBUS paths, Pi buck, provisional display converter, 3.3 V housekeeping buck, and SWD.
Provisional / Validation Required
- STUSB4710 library entries lack attached datasheets; source-controller pin usage and PDO-selection wiring require validation against the official ST document.
- Display conversion is provisionally represented by ST1S14PHR. It cannot produce a regulated 20 V output from a nominal 20 V bus and is not a complete digitally programmable multi-PDO implementation. A buck-boost or direct 20 V bypass plus selectable lower-voltage converter is required in revision 2.
- TCPP03-M20 devices are instantiated for each connector but their detailed pass-FET/current-sense support network is not yet wired; official reference design extraction is required.
- USB data and SBU pins are intentionally unused for this power-only hub.
Project Overview
Intended Use
What the Device Should Do
Main Features
System Architecture
Hardware Subsystems
Interfaces and Connections
Power and Runtime Expectations
Power Tree and Power Budget
Manufacturing and Assembly Expectations
Firmware-Relevant Hardware Requirements
Physical Design Expectations
Important Design Decisions
Assumptions
Change Notes
Provisional / Validation Required
