Gaming Hardware Concept
Worked for 1 min 13 sec
I’m blocked because your account has no available ACUs, so I can’t run any more layout or DRC cleanup tools right now.
Accomplished:
- Applied a 6-layer stackup attempt and an explicit 6-layer stackup definition.
- Cleared stale partial routing.
- Spread the U1/U2/U6 cluster and support passives for better BGA escape.
- Re-ran the router; it applied 884 routing nodes.
- USB signal-integrity checks queried for USB returned no matching issues, but final DRC is not clean.
Open items:
- Final DRC still shows 33 airwire errors.
- Final DRC also shows 67 invalid Smart Via layer errors, indicating the same stackup recognition issue remains: stackup inspection shows the new stackup name, but layout summary still reports 2 copper layers.
- Some USB1 routing airwires remain in the final DRC list.
Suggested next steps when ACUs are available:
- Resolve the stackup/copper-layer recognition issue first.
- Delete or remap invalid Smart Vias after the stackup is recognized correctly.
- Surgically route the remaining USB1, MCU power, UART, FlexSPI, and debug airwires.
- Run final DRC again before treating the PCB as manufacturing-ready.
Check ACU status
Fix stackup issue
List airwires
Remap Smart Vias
Refine this doc
Ask about this doc
PROX Technical Specification
Status: Draft architecture for prototype
Date: 2026-07-26
1. Project Overview
PROX is a four-port USB-C gaming/accessibility hardware interface concept with ports labeled:
- CONTROLLER — physical USB controller input
- CONSOLE — console/host-facing USB HID device output
- PC — configuration, telemetry, logging, and development control
- POWER — dedicated USB-C power input
The intended legitimate use is HID translation, accessibility controller adaptation, lab testing, and controller firmware experimentation. This specification does not cover bypassing console authentication, anti-cheat systems, or proprietary security mechanisms.
2. Top-Level Recommendation
Use a high-performance MCU with two real USB controllers for the latency-critical path:
- USB host for the physical controller
- USB device for the console/target host
Use a separate USB-to-UART bridge for the PC port so PC logging/configuration never competes with the real-time HID path.
Recommended prototype architecture:
- Main MCU: STM32H7/F7-class or NXP i.MX RT-class MCU
- Controller port: USB host / Type-C DFP
- Console port: USB device / Type-C UFP
- PC port: USB-C UFP into USB-UART bridge, then UART/SPI to MCU
- Power port: USB-C 5 V sink, optional USB-PD sink in later revision
3. MCU & USB Hardware Selection
3.1 Architecture Options
Table
| Option | Summary | Pros | Risks / Cons | Recommendation |
|---|---|---|---|---|
| RP2040 + native USB device + PIO USB host | RP2040 uses native USB for console/PC and PIO for controller host | Low cost, familiar, strong hobby ecosystem | Only one native USB controller; PIO host is timing-sensitive; edge-case issues with composite HID, low-speed devices, reconnects, hubs; harder to guarantee latency | Good for experiments only |
| RP2350 + native USB + PIO USB host | Similar approach with newer Pico-class silicon | Faster, more headroom than RP2040 | PIO host still not equivalent to hardened USB host peripheral; newer ecosystem | Experimental / proof-of-concept |
| STM32F7/H7 with two USB OTG controllers | One USB host, one USB device; PC via bridge | Mature USB peripherals, strong real-time performance, good embedded tooling | More complex board design; HS may need ULPI PHY | Recommended |
| NXP i.MX RT106x/117x | High-performance MCU with multiple USB controllers | Excellent speed, strong USB capability, Teensy ecosystem useful for prototyping | More advanced layout/firmware complexity | Also recommended |
| MCU + MAX3421E USB host | External SPI USB host controller | Simple conceptual add-on | SPI bottleneck, latency, full-speed limits, less robust for tight timing | Not preferred |
3.2 Recommended MCU Direction
Primary candidate family:
- STM32H723/H743/H750/H735 or similar STM32H7 with USB OTG FS and USB OTG HS
- Alternative: STM32F723/F733 class if available and sufficient
- Alternative: NXP i.MX RT1062/1064/1170
Recommended USB assignment for STM32H7-style design:
Table
| MCU Peripheral | External Port | Role | Notes |
|---|---|---|---|
| USB OTG HS + ULPI PHY | CONTROLLER | Host | Use for physical controller; supports robust host operation |
| USB OTG FS | CONSOLE | Device | Presents PROX as HID/accessibility/test device |
| UART or SPI | PC bridge | Control/logging | PC port handled by CP2102N/FT231X/CH343/MCP2221A class bridge |
3.3 Why Not Make PC a Third Native USB Port?
Most MCUs do not provide three independent USB device/host controllers. The PC port is not timing-critical, so a USB-UART bridge is the cleanest split:
- keeps HID path deterministic
- isolates debug/log traffic
- simplifies firmware scheduling
- avoids composite USB complications on the console-facing device stack
4. Hardware Block Diagram
Diagram
5. USB-C Port Electrical Roles
Table
| Port | USB Role | Type-C Role | CC Pins | VBUS Behavior | Data Pins |
|---|---|---|---|---|---|
| CONTROLLER | USB host | DFP/source | Rp on CC1 and CC2 | Sources 5 V through current-limited switch | D+/D- to host PHY/controller |
| CONSOLE | USB device | UFP/sink | Rd on CC1 and CC2 | Sense only; do not source or backfeed | D+/D- to MCU USB device |
| PC | USB device | UFP/sink | Rd on CC1 and CC2 | Powers/senses bridge only; isolate from system if needed | D+/D- to USB-UART bridge |
| POWER | Power input | UFP/sink | Rd or PD sink controller | Main 5 V input to system | Data not required |
USB 2.0 Type-C Wiring Notes
For USB 2.0-only Type-C receptacles:
- Connect A6 and B6 together as D+
- Connect A7 and B7 together as D-
- CC1 and CC2 require correct role-specific termination
- Add ESD protection close to each connector
- Avoid VBUS backfeed between ports
- Route D+/D- as 90 ohm differential pairs with short, symmetric traces
- Use a 4-layer PCB minimum for reliable USB 2.0 high-speed routing
6. Draft Pinout / Signal Assignment
Exact MCU pins depend on the selected package, but the functional pinout should be reserved as follows.
6.1 Main MCU Signals
Table
| Function | Suggested MCU Peripheral | Direction | Connects To | Notes |
|---|---|---|---|---|
| Controller USB D+/D- | USB OTG HS via ULPI | bidirectional | ULPI PHY | Host path for controller |
| ULPI_D0..D7 | USB HS ULPI | bidirectional | USB3300/USB3320 PHY | 8-bit ULPI bus |
| ULPI_CLK | USB HS ULPI | input | ULPI PHY | Usually 60 MHz from PHY |
| ULPI_STP/NXT/DIR | USB HS ULPI | mixed | ULPI PHY | Required control signals |
| Console USB D+ | USB OTG FS DP | bidirectional | CONSOLE USB-C D+ | Device path |
| Console USB D- | USB OTG FS DM | bidirectional | CONSOLE USB-C D- | Device path |
| Console VBUS sense | GPIO/ADC | input | CONSOLE VBUS divider | Detect attach/power |
| Controller VBUS enable | GPIO | output | VBUS power switch EN | Turns on 5 V source |
| Controller overcurrent | GPIO interrupt | input | VBUS switch FLG/OC | Fault detection |
| PC control UART TX/RX | UART | bidirectional | USB-UART bridge | Config/logs |
| PC bridge reset | GPIO | output | USB-UART bridge reset | Optional |
| Status RGB | PWM/SPI | output | RGB LED driver | Optional front light strip |
| BOOT0/boot select | strap/GPIO | input | header/button | Firmware recovery |
| SWD/JTAG | debug | bidirectional | programming header | Mandatory for prototype |
| Reset | reset | input | button/header | Manual recovery |
6.2 USB Host PHY Signals
Recommended PHY examples: USB3300, USB3320, USB3343, or equivalent ULPI PHY supported by the MCU reference design.
Table
| PHY Signal | Connects To | Notes |
|---|---|---|
| DP/DM | CONTROLLER port D+/D- through ESD/CMC | Differential USB pair |
| VBUS | Controller VBUS after switch | Host VBUS supply/sense |
| ULPI bus | MCU OTG HS ULPI pins | Follow MCU reference layout |
| REFCLK/XTAL | crystal or clock source | Per PHY datasheet |
| RESETB | MCU GPIO or reset supervisor | Controlled startup |
7. Power Delivery and Power Tree
7.1 Prototype Power Strategy
Start with a simple 5 V USB-C sink on the POWER port. Add USB-PD only if the product later needs more than 5 V/3 A or a higher-voltage internal rail.
Power tree:
Diagram
7.2 Initial Power Budget Estimate
Table
| Load | Rail | Estimated Current | Notes |
|---|---|---|---|
| STM32H7 / i.MX RT MCU | 3.3 V | 100-300 mA | Depends on clock, cache, USB activity |
| ULPI USB PHY | 3.3 V | 40-80 mA | Check selected PHY |
| USB-UART bridge | 3.3 V | 10-30 mA | CP2102N/FT231X class |
| RGB LEDs | 5 V | 0-1000 mA | Highly dependent on LED count/brightness |
| Attached controller | 5 V | 100-500 mA | Host port current limit recommended |
| Misc/ESD/leakage | 3.3/5 V | 20-50 mA | margin |
Recommended input rating for prototype: 5 V, 1.5-3 A, depending on RGB LED brightness and controller current limit.
8. USB Signal Integrity and PCB Stackup
Minimum recommended stackup: 4-layer PCB.
Suggested layers:
Table
| Layer | Purpose |
|---|---|
| L1 Top | Components and USB differential pairs |
| L2 Inner 1 | Solid ground plane |
| L3 Inner 2 | Power distribution |
| L4 Bottom | Low-speed routing and secondary signals |
USB 2.0 routing targets:
- Differential impedance: 90 ohm differential
- Match D+/D- within approximately 0.5-2 mm; tighter is better
- Keep high-speed USB on top layer where possible
- Avoid vias in USB pairs where possible
- Place ESD diodes at connectors before long traces
- Avoid stubs from unused connector pins or test pads
- Keep ground continuous under all USB traces
9. Firmware Architecture
9.1 Firmware Goals
- Receive controller HID reports from CONTROLLER USB host port
- Parse HID report descriptors and normalize input state
- Apply translation/mapping profiles
- Keep latest console-facing HID report prebuilt and ready
- Respond to console USB IN polls with minimal latency
- Handle console OUT reports if rumble/LED feedback is supported
- Accept PC configuration/logging commands without disturbing HID timing
9.2 Firmware Block Diagram
Diagram
9.3 Real-Time HID Data Path
Critical path:
- Controller USB host receives interrupt IN report
- USB host callback timestamps report
- Report is copied into a preallocated buffer
- HID parser converts report to normalized state
- Mapping engine builds console report
- Console report buffer pointer is atomically swapped
- Console USB device IN endpoint returns the latest report on next host poll
Hard rules:
- No dynamic memory allocation in the report path
- No blocking I/O in USB callbacks
- No printf logging in high-priority callbacks
- PC commands run at lower priority than USB host/device interrupts
- Use preallocated buffers and ring queues
- Use double buffering for console HID reports
- Use watchdog and USB stack recovery for disconnect/reset events
9.4 Timing Reality Check
For USB full-speed HID, the host normally polls interrupt endpoints on a 1 ms USB frame. Therefore, the practical target is:
Process each incoming report and stage the translated output before the next console IN poll.
Internal processing should target:
Table
| Stage | Target |
|---|---|
| USB host callback to normalized state | <100 us typical |
| Mapping and report build | <50 us typical |
| Atomic buffer update | <10 us |
| Worst-case report-path firmware latency | <250 us target |
This supports sub-millisecond internal latency, but end-to-end external timing is still constrained by USB host polling intervals and controller/console behavior.
9.5 PC Serial Protocol
The PC port should be for non-real-time control only.
Recommended transport:
- USB-UART bridge at 1-3 Mbaud initially
- Binary framed protocol with CRC
- Optional SLIP/COBS framing to avoid delimiter ambiguity
Suggested message categories:
Table
| Category | Direction | Purpose |
|---|---|---|
| HELLO / VERSION | PC to device | identify firmware/protocol version |
| SET_PROFILE | PC to device | load mapping profile |
| GET_PROFILE | PC from device | read current mapping |
| SET_LED | PC to device | set RGB/status pattern |
| GET_STATS | PC from device | report latency counters, USB state |
| LOG_EVENT | device to PC | async diagnostics |
| ENTER_BOOTLOADER | PC to device | controlled firmware update mode |
The PC protocol must not be required for normal controller-to-console operation.
9.6 USB Compatibility Requirements
Minimum firmware support:
- USB full-speed HID controllers
- HID report descriptor parsing
- Composite devices with multiple interfaces
- Disconnect/reconnect handling
- USB reset/suspend/resume
- Console OUT reports if force feedback is needed
Explicit risk:
- Many game consoles do not accept arbitrary generic HID devices as full controllers. Compatibility may require official development modes, accessibility APIs, licensed protocols, or documented target-host support.
10. Prototype BOM
10.1 Core Compute and USB
Table
| Ref | Qty | Part / Type | Example MPNs | Notes |
|---|---|---|---|---|
| U1 | 1 | Main MCU, dual USB-capable | STM32H723/STM32H743/STM32H750, STM32F723/F733, NXP i.MX RT1062 | Final selection after package, availability, and USB library review |
| U2 | 1 | ULPI USB HS PHY | USB3300, USB3320, USB3343 | Needed if MCU HS USB uses external PHY |
| U3 | 1 | USB-UART bridge | CP2102N, FT231X, CH343, MCP2221A | PC configuration/debug port |
| Y1 | 1 | MCU crystal/oscillator | per MCU reference design | USB requires accurate clocking |
| Y2 | 1 | PHY crystal/clock | per PHY reference design | if not clocked from MCU/system clock |
| JTAG/SWD | 1 | Debug connector | Tag-Connect or 2x5 1.27 mm SWD | Required for bring-up |
10.2 USB-C Connectors and Protection
Table
| Ref | Qty | Part / Type | Example / Notes |
|---|---|---|---|
| J1 | 1 | USB-C receptacle, CONTROLLER | USB 2.0 Type-C receptacle, DFP wiring |
| J2 | 1 | USB-C receptacle, CONSOLE | USB 2.0 Type-C receptacle, UFP wiring |
| J3 | 1 | USB-C receptacle, PC | USB 2.0 Type-C receptacle, UFP wiring |
| J4 | 1 | USB-C receptacle, POWER | USB-C power input only |
| D1-D4 | 4 | USB ESD diode arrays | Low-capacitance USB 2.0-rated arrays |
| CMC1-CMC3 | 0-3 | USB common-mode choke | Optional; validate signal quality |
| Rcc | as needed | CC resistors | Rp for controller, Rd for console/PC/power |
| Rser | as needed | USB series resistors | Only if MCU/PHY reference design recommends |
10.3 Power Management
Table
| Ref | Qty | Part / Type | Example MPNs | Notes |
|---|---|---|---|---|
| U4 | 1 | Input eFuse / protection switch | TPS2595/TPS2596 class, AP2265/AP2331 class depending current | Protect 5 V input |
| U5 | 1 | Controller VBUS power switch | TPS2051/TPS2553/TPS2561, AP2331/AP2553, MIC2005 | Current-limited host power |
| U6 | 1 | 3.3 V regulator | 500 mA-1 A buck or LDO | Buck preferred if LEDs/controller draw raise thermals |
| D5 | 1 | Input TVS diode | USB VBUS-rated TVS | Place near POWER connector |
| F1 | 1 | Fuse/polyfuse optional | sized for input current | Optional if eFuse used |
| TP | many | Test points | VBUS, 5V_SYS, 3V3, CC1/CC2, reset, boot, SWD | Important for bring-up |
10.4 User Interface / Enclosure Features
Table
| Ref | Qty | Part / Type | Notes |
|---|---|---|---|
| LED1 | optional | RGB LED strip/frame | Consider external 5 V addressable LEDs or onboard RGB LEDs |
| U7 | optional | LED driver / level shifter | Needed if using 5 V addressable LEDs from 3.3 V MCU |
| SW1 | 1 | Reset button | Prototype convenience |
| SW2 | 1 | Boot/mode button | Firmware recovery/profile mode |
| LABEL | 1 | Product sticker | Device ID, firmware, compliance placeholder |
11. Development and Validation Plan
Stage 1 — Dev Board Proof
- Use STM32H7 or i.MX RT development board
- Connect controller to USB host port
- Expose console-facing HID to a PC first, not a console
- Add PC logs over UART bridge
- Validate report parsing and mapping
Stage 2 — Timing Validation
- Timestamp host report receipt
- Timestamp console report staging
- Measure worst-case latency under logging load
- Confirm PC protocol cannot block HID path
- Use USB protocol analyzer if available
Stage 3 — First Custom PCB
- Include all four USB-C connectors
- Add SWD/JTAG, reset, boot pins
- Add test points for VBUS/CC/D+/D-/3V3/5V
- Add jumpers or 0 ohm links for isolating power paths
- Use 4-layer stackup with solid ground plane
Stage 4 — Compatibility Testing
- Test generic HID controllers
- Test composite controllers
- Test disconnect/reconnect/reset/suspend/resume
- Test console/target host only within legitimate supported modes
- Test OUT reports if rumble/feedback is supported
12. Key Design Risks
Table
| Risk | Impact | Mitigation |
|---|---|---|
| Console rejects generic HID | Product may not work with target console | Start with PC/development host; verify legitimate supported console interfaces early |
| USB host compatibility | Some controllers may not enumerate | Use native USB host controller, parse descriptors, test multiple devices |
| Timing jitter | Input latency or missed reports | Keep PC traffic out of real-time path, use priorities and double buffers |
| VBUS backfeed | Damage or unreliable behavior | Isolate all VBUS domains; use switches/sense-only dividers |
| USB signal integrity | Enumeration failures | 4-layer board, 90 ohm diff routing, ESD near connectors |
| Firmware complexity | Delays | Build staged prototype before custom PCB |
13. Open Decisions
- Select exact target MCU family/package.
- Decide whether the prototype targets PC-host HID only first or a specific legitimate console/development environment.
- Decide whether RGB LEDs are decorative only or firmware-controlled status indicators.
- Decide if USB-PD is needed on the POWER port or if 5 V-only is sufficient.
- Define the first supported controller set: generic HID gamepad, keyboard/mouse, XInput-style controller, or a specific accessibility controller.
14. Current Architecture Decision
For the first real prototype, PROX should use:
- STM32H7/F7 or NXP i.MX RT-class MCU
- native USB host for CONTROLLER
- native USB device for CONSOLE
- separate USB-UART bridge for PC
- dedicated isolated USB-C power input
- 4-layer PCB with controlled USB routing
This is the most robust path for reliable HID timing and USB compatibility while keeping the PC configuration/logging channel isolated from the real-time report path.
1. Project Overview
2. Top-Level Recommendation
3. MCU & USB Hardware Selection
3.1 Architecture Options
3.2 Recommended MCU Direction
3.3 Why Not Make PC a Third Native USB Port?
4. Hardware Block Diagram
5. USB-C Port Electrical Roles
USB 2.0 Type-C Wiring Notes
6. Draft Pinout / Signal Assignment
6.1 Main MCU Signals
6.2 USB Host PHY Signals
7. Power Delivery and Power Tree
7.1 Prototype Power Strategy
7.2 Initial Power Budget Estimate
8. USB Signal Integrity and PCB Stackup
9. Firmware Architecture
9.1 Firmware Goals
9.2 Firmware Block Diagram
9.3 Real-Time HID Data Path
9.4 Timing Reality Check
9.5 PC Serial Protocol
9.6 USB Compatibility Requirements
10. Prototype BOM
10.1 Core Compute and USB
10.2 USB-C Connectors and Protection
10.3 Power Management
10.4 User Interface / Enclosure Features
11. Development and Validation Plan
Stage 1 — Dev Board Proof
Stage 2 — Timing Validation
Stage 3 — First Custom PCB
Stage 4 — Compatibility Testing
12. Key Design Risks
13. Open Decisions
14. Current Architecture Decision
