USB↔UART/I²C/SPI/GbE Bridge ICs: Drivers & EEPROM
← Back to:Interfaces, PHY & SerDes
This page shows how to turn USB into UART/I²C/SPI/GbE reliably for debug, configuration, production test, and field service—without getting trapped by driver binding, EEPROM/NVM misconfiguration, or fragile bus timing. It provides a step-by-step selection logic and an engineering checklist with measurable pass criteria to make bring-up repeatable and recoverable.
Definition & scope guard
USB↔UART/I²C/SPI/GbE bridge ICs convert a USB host connection into practical debug and control links—serial console, register access, SPI transactions, or a virtual Ethernet interface—so devices can be configured, tested, and serviced across bring-up, production, and field diagnostics.
Practical definition: a USB device that exposes one or more host-visible functions (serial or network) and maps them to target-side pins (UART/I²C/SPI) or a MAC-facing Ethernet port, often with EEPROM/NVM for identity and default behavior.
- Bring-up: stable enumeration + known interface path (COM / tty / network adapter) + predictable latency.
- Production: deterministic identity (serial number policy) + safe configuration (rollback) + test hooks (loop/echo/transaction checks).
- Field diagnostics: minimal tooling for log capture, register reads, SPI device checks, or service networking.
In-scope (deep coverage on this page)
- USB enumeration and driver binding behavior (CDC-ACM / vendor driver / ECM/RNDIS/NCM) with first-probe checks.
- EEPROM/NVM configuration strategy: identity, defaults, uniqueness, and safe rollback paths.
- Transaction-level reliability on UART/I²C/SPI/GbE: latency, buffering, bus hangs, CS boundaries, throughput stability.
- Board integration essentials: power attributes consistency, basic clock/power hygiene, minimal layout rules.
- Production readiness: deterministic identity, test sequences, and pass criteria (threshold placeholders).
Out-of-scope (mention only → link to dedicated pages)
- USB signal conditioning (Hub/Repeater/Redriver/Retimer, USB PHY margining) — keep to interface-level notes only.
- High-speed protection deep dive (TVS/ESD arrays, CM chokes, full EMI strategy) — keep to “selection criteria + layout guardrails”.
- Ethernet PHY/magnetics/TSN timing details — keep to driver mode and basic virtual NIC verification only.
- Cable/connector ecosystems and compliance certification workflows — reference-only, no expansion here.
Arbitration rule: shared topics stay at “criteria + first diagnostic split”; deep theory and part comparisons belong to the dedicated sibling pages.
Selection logic (decision flow) — OS/driver strategy → interface mapping → latency/throughput needs → EEPROM policy → production constraints.
Engineering checklist — design → bring-up → production → field, each with “pass criteria (X threshold)” placeholders.
FAQ failure triage — enumeration/identity/latency/bus-hang/dropout mapped to the first probe point and a safe fix.
Diagram focus: functional blocks and ownership boundaries (drivers/EEPROM/target engines). No USB PHY/ESD deep-dive here.
Use-cases mapped to interfaces
Interface selection becomes straightforward when tasks are mapped to “what must be observed or controlled” and the first diagnostic split is defined up front. The goal is fast bring-up and predictable behavior—not chasing part numbers first.
- Goal: stable interactive text I/O (shell, logs, bootloader commands).
- Needed bandwidth: typically low-to-moderate (X range), but buffering/packetization dominates perceived speed.
- Latency sensitivity: high for interactive shells; low for bulk logs. Watch “laggy terminal” symptom.
- Tooling: device manager/lsusb + terminal + optional line-control test (RTS/CTS).
- First probe: driver binding path + latency timer / buffer settings.
- Pass criteria: stable port identity across replug; round-trip echo delay ≤ X ms; no overrun at target rate.
- Goal: deterministic register reads/writes and safe recovery from bus-hang states.
- Needed bandwidth: usually modest; correctness and compatibility dominate (clock stretching, repeated start).
- Latency sensitivity: medium; interactive tuning benefits from predictable transaction timing.
- Tooling: bus scan/read tool + optional scope/logic analyzer for SCL/SDA states.
- First probe: confirm bridge supports needed protocol features (stretching, repeated start), then check pull-up/cap load criteria.
- Pass criteria: repeated 1k transactions with zero NACK/timeouts; bus recovery clears stuck-low within X ms.
- Goal: reliable framed transactions (CS boundaries) for device ID, register reads, and flash operations.
- Needed bandwidth: can be high; stability depends on CPOL/CPHA and CS setup/hold, not only clock rate.
- Latency sensitivity: medium; batch/burst performance matters more than per-byte latency.
- Tooling: SPI transaction tool + logic analyzer for CS/SCLK/MOSI/MISO.
- First probe: verify Mode (0/1/2/3) and CS hold/gap match the target’s transaction framing.
- Pass criteria: repeated ID/readback consistency at target speed; zero framing errors over X bursts.
- Goal: a stable virtual Ethernet adapter for provisioning, diagnostics, and production networking.
- Needed bandwidth: moderate-to-high; driver mode (ECM/RNDIS/NCM) and MTU behavior often dominate real throughput.
- Latency sensitivity: low-to-medium; stability and reconnect behavior matter more than ping minima.
- Tooling: OS network panel + ipconfig/ifconfig + throughput test tool (pass/fail threshold X).
- First probe: confirm the driver class bound as expected (ECM/RNDIS/NCM) and verify link persistence under load.
- Pass criteria: no disconnects in X minutes sustained traffic; packet loss ≤ X%.
Quick picker (no wide tables)
UART
Best for: console/logs · Avoid when: strict framing needed · First check: latency timer / binding
I²C
Best for: registers/calibration · Avoid when: bus hangs unmanaged · First check: stretching + recovery
SPI
Best for: flash/control · Avoid when: CS boundaries unclear · First check: CPOL/CPHA + CS hold/gap
GbE (USB NIC)
Best for: management/test at scale · Avoid when: driver class mismatch · First check: ECM/RNDIS/NCM bind
If a topic begins to require USB PHY, protection part selection, or Ethernet PHY/magnetics analysis, keep it to “criteria + link” and move the deep dive to the dedicated sibling page.
Architecture types
A USB bridge behaves like a small system: descriptors and interfaces decide the host driver path, endpoints define transfer behavior, FIFO and clock-domain crossings shape latency, and target-side engines implement UART/I²C/SPI or a virtual Ethernet function. Architecture choice is therefore a reliability choice.
- What it is: host-visible interfaces + endpoints, a FIFO/packetization layer, and a dedicated target engine (UART/I²C/SPI).
- Why it exists: minimal deployment complexity and predictable data path for bring-up and scripted test.
- Typical failure modes: “laggy terminal” (latency timer/FIFO), intermittent I²C NACK/timeouts (protocol feature mismatch), SPI readback inconsistency (CS boundary / CPOL/CPHA).
- First probe: verify driver binding → verify endpoint type/throughput expectations → verify engine features (stretching, repeated start, CS hold/gap).
- Pass criteria: stable node identity across replug; X transactions with zero errors; worst-case command round-trip ≤ X ms.
- What it is: a bridge data path plus GPIOs used for reset, boot straps, mode pins, and UART flow control.
- Why it exists: automation: deterministic “power-cycle → enter mode → program → verify” loops for production and recovery.
- Typical failure modes: enumerates but target is unresponsive (wrong boot mode), rare “wrong mode on cold start” (strap sampling window), flow control overruns (RTS/CTS direction or polarity mismatch).
- First probe: check GPIO default levels at power-up; confirm reset/boot timing relative to target requirements; confirm firmware/tool toggles the correct pins.
- Pass criteria: correct mode entry rate ≥ X%; strap stability margin ≥ X; zero overruns over X MB logs.
- What it is: a virtual USB network function (ECM/RNDIS/NCM) mapped to an Ethernet-facing data path with a MAC-like wrapper and offload knobs.
- Why it exists: scalable provisioning and diagnostics: test racks and service tools can use standard IP workflows.
- Typical failure modes: network adapter missing on one OS (class mismatch), appears but drops under load (power/USB suspend/queue settings), unstable throughput (driver mode/MTU behavior).
- First probe: confirm which class actually bound; run sustained traffic and watch disconnect counters; verify MAC address/identity policy from NVM.
- Pass criteria: no disconnects over X minutes; loss ≤ X%; throughput ≥ X.
Scope guard: PHY/magnetics and system EMI are not expanded here; only the USB NIC class/identity/stability path is covered.
- What it is: multiple interfaces/functions in one USB device, each requiring correct interface descriptors and OS binding behavior.
- Why it exists: consolidate tooling: a serial console plus a control channel (HID) plus config storage (MSC) can reduce field friction.
- Typical failure modes: one function binds to the wrong driver; endpoints starve each other; updates/config disrupt the console under load.
- First probe: confirm interface numbers and class codes match expected binding; verify each function independently before combined stress.
- Pass criteria: each function appears and operates across target OS set; replug consistency ≥ X%; stress test for X cycles without misbind.
*RGMII is shown only as a generic “Ethernet-facing” pin concept; PHY/magnetics details are handled on the Ethernet PHY pages.
USB enumeration & driver model
Most “bridge failures” are not UART/I²C/SPI problems; they are binding problems. Enumeration is a pipeline: attach → descriptors → interfaces → driver bind → device node → function check. Each stage has a first probe point and a minimal fix.
CDC-ACM: lower deployment friction (typical OS-native binding)
Use when predictable “COM/tty appears” matters more than custom features. Validate node stability and latency behavior early.
Vendor driver: higher control, higher lifecycle cost
Use when special modes, tighter latency knobs, or proprietary protocols are required. Plan for signing/distribution and version pinning.
- Symptoms: device appears but no COM/tty; COM appears but data is garbled; COM number changes unpredictably.
- First probe: confirm class/subclass/protocol + which driver bound; confirm the expected device node exists.
- Minimal fix: align descriptors to the intended class, or standardize on CDC-ACM where feasible; pin driver package versions where not.
- Pass criteria: replug X times with identical binding; node appears within X s; interactive echo delay ≤ X ms.
Pick the NIC class by target OS set and deployment constraints. Treat the class as a binding contract: if the class binds incorrectly, no amount of Ethernet-side tuning will help.
- Symptoms: NIC missing on one OS; NIC appears but DHCP fails; throughput unstable; disconnects under sustained load.
- First probe: verify which class actually bound; verify link-up and IP path (ping) before throughput tests.
- Minimal fix: switch to a more compatible class for the OS set or provide a controlled mode selection (if supported); standardize MTU and reconnection behavior tests.
- Pass criteria: stable link for X minutes at sustained traffic; loss ≤ X%; throughput ≥ X.
- Risk pattern: production station passes, field fails after OS update; or stations differ due to driver drift.
- Minimal actions: pin driver package version; standardize VID/PID + serial policy; add a “driver health check” step to the station checklist.
- First probe: confirm the active driver version matches the approved build; verify binding is deterministic across replug and across stations.
- Pass criteria: station health check ≥ X% pass rate; OS update within X versions does not break binding.
Keep this chapter focused on deployment risks and verification points; OS step-by-step tutorials belong to tooling documentation, not this page.
If the device is not recognized at all
First split: power/attach vs enumeration. Confirm the OS reports attach events; then confirm a device descriptor exists.
If the device appears but no COM/tty/NIC node
First split: descriptors/interfaces vs driver binding. Verify class codes, interface count, and composite grouping match the intended driver.
If the node exists but the function fails
First split: endpoint behavior/FIFO vs target engine features. Run a minimal function test (echo/scan/ping) and then stress.
Minimal sources to consult: Device Manager / System logs / lsusb / dmesg for enumeration and binding evidence; then a function-specific “hello test” for UART/I²C/SPI/NIC.
Pass criteria: enumeration completes within X s; node appears deterministically; minimal function test passes for X consecutive cycles.
EEPROM / NVM configuration strategy
NVM is both identity and behavior control. A small set of fields directly impacts OS driver binding and node creation (COM/tty/NIC). A safe strategy separates locked identity, bind-impact fields, and tunable behavior, and requires a rollback path to prevent “soft-brick” states.
The MVP keeps enumeration and binding deterministic while allowing limited tuning for interactive debug.
Lock (identity)
VID/PID, iProduct/iManufacturer, serial policy (placeholder), and (for USB↔GbE) MAC policy (placeholder).
Bind-impact (do not “tune casually”)
Class codes, interface count, endpoint layout, and power attributes (bus/self-powered, MaxPower, Remote Wakeup).
Tunable (behavior defaults)
Default baud/format, latency timer, buffer policy, and GPIO default states (only if rollback is guaranteed).
- Symptoms: device enumerates but no COM/tty/NIC node; node exists but behavior changes across replug; intermittent reconnect after suspend/resume.
- First probe: confirm binding evidence (class/interface) before changing any behavior defaults; then confirm power attributes match the intended deployment.
- Pass criteria: replug X times with identical binding; enumeration ≤ X s; minimal function test passes X consecutive cycles.
Production failures often come from identity drift and inconsistent defaults across stations/batches. The goal is a deterministic binding contract and audited write/verify steps.
- Uniqueness policy (placeholders): serial number format, uniqueness scope, and traceability; (for NIC) MAC allocation and rollback rules.
- Versioning: NVM image version field and a compatibility rule that forbids “interface structure changes” after release.
- Station audit: write → read-back verify (CRC/Checksum) → minimal function acceptance (echo/scan/ping) → log the resulting binding evidence.
- Pass criteria: uniqueness collisions = 0 (or ≤ X ppm); read-back verify ≥ X%; replug consistency ≥ X% across the OS set (placeholder).
Safety design elements
- Factory default image (always bindable)
- Recovery mode trigger (strap/GPIO/sequence — placeholder)
- Dual image A/B + validity flag
- Atomic commit: write → CRC verify → set “valid”
Rescue SOP (minimal, executable)
- Classify: is the device descriptor visible (enumeration) or only the function is missing (binding)?
- Enter recovery mode (trigger placeholder) and confirm recovery identity appears.
- Restore factory image or roll back to the last valid A/B slot.
- Verify binding and minimal function check (echo/scan/ping).
- Lock down bind-impact fields or enable write protection (if supported).
Pass criteria: recovery entry ≥ X%; restore time ≤ X; replug stability X cycles; minimal test passes X times.
UART bridge deep dive
UART performance is shaped by USB framing and buffering. The practical knobs are latency timers, FIFO policy, and flow-control wiring/enablement. Treat each knob as parameter → symptom → first probe → fix → pass criteria.
- Parameter: baud rate + data format; endpoint/packetization + FIFO depth.
- Symptom: theoretical baud looks sufficient, but sustained payload rate is lower or “bursty”.
- First probe: measure effective payload bytes over X s, not peak bursts; record error counters and overruns.
- Fix: align FIFO/flush policy with workload (interactive vs streaming); avoid mixing interactive console and heavy log streams on one setting.
- Pass criteria: sustained payload ≥ theoretical × X%; zero overruns; stable for X min.
- Parameter: latency timer, flush thresholds, host-side read size.
- Symptom: “sticky” interactive console; single-character commands feel delayed; short responses arrive in chunks.
- First probe: run a single-character echo test and capture RTT distribution (mean + jitter).
- Fix: reduce latency timer for interactive workloads; keep a separate profile for streaming logs to preserve throughput.
- Pass criteria: echo RTT ≤ X ms; RTT jitter ≤ X ms.
- Parameter: hardware flow control enable + RTS/CTS wiring + polarity expectation.
- Symptom: overruns and missing bytes at high log rates; or link “hangs” with flow control enabled.
- First probe: confirm RTS/CTS direction and idle levels; confirm the host driver actually enables HW flow control.
- Fix: enable HW flow control when the target has limited RX buffering; otherwise disable and shape throughput with buffering/flush policy.
- Pass criteria: overrun counter = 0 over X MB; no deadlock across X reconnect cycles.
- Parameter: DTR/RTS default states, tool behavior on open/close, GPIO mapping (if reused as reset/boot).
- Symptom: opening the port resets the target or forces boot mode; automation becomes “random” across tools.
- First probe: observe line transitions on port open/close; confirm which line is physically tied to reset/boot.
- Fix: move reset/boot control to explicit GPIO scripting where possible; otherwise fix default states in NVM and standardize tooling.
- Pass criteria: port open/close causes no unintended mode change; X reconnect cycles remain stable.
- Parameter: BREAK support and duration control; 9-bit feature availability; RS-485 direction (DE/RE) timing mode (if available).
- Symptom: bootloader entry works on one host but not another; multi-drop addressing fails; half-duplex direction change drops bytes.
- First probe: verify the bridge truly supports the required special mode and exposes a deterministic control path (not a best-effort emulation).
- Fix: prefer explicit GPIO/strap for mode entry; treat BREAK as auxiliary. For RS-485, validate DE timing against TX-complete behavior (bridge-side only).
- Pass criteria: special-mode success ≥ X% across the host set; turnaround ≤ X; zero dropped bytes over X cycles.
Scope guard: RS-485 electrical layer, termination, and EMC are handled on dedicated RS-485 pages; only bridge-side feature differences and validation points are included here.
UART bridge minimal debug checklist (fast acceptance)
- Binding evidence is consistent (node identity stable across replug X times).
- Baseline echo test passes (RTT mean ≤ X ms, jitter ≤ X ms).
- Sustained payload test runs X min with zero overruns and zero framing/parity errors.
- Flow control behavior is correct (RTS/CTS enabled only when required; no deadlock under stress).
- Open/close of the port does not unintentionally reset or change target mode.
- If special modes are required, success ≥ X% across the host/tool set (placeholder).
I2C Bridge Deep Dive
I2C bridge failures are most often caused by timing and compatibility gaps (stretching, repeated-start, ACK behavior) and by “stuck bus” conditions. This section focuses on executable verification and recovery steps with pass criteria placeholders.
- Speed modes: verify supported modes as a capability target (Std/Fast/Fm+ = X placeholder), then validate on the actual bus.
- Clock stretching: confirm whether stretching is transparent, limited-window, or treated as timeout. Record timeout threshold (≤ X ms).
- Repeated-start: verify “write register + repeated-start + read” is preserved (no substituted STOP) for devices that require it.
- ACK/NACK behavior: determine how NACK is handled (auto STOP vs hold vs immediate retry) and standardize the expected error signature.
Pull-ups & bus capacitance (measurement-only)
Use rise-time observation and repeatable thresholds rather than guessing resistor values. Pass criteria: rise time ≤ X (placeholder) at the target speed; NACK rate ≤ X% over X transactions.
Scope guard: detailed physical-layer design (routing/EMI/edge-shaping networks) belongs on dedicated I2C electrical pages; only decision criteria and measurement methods are included here.
- Freeze new transactions: stop issuing new I2C operations to avoid compounding errors.
- Classify the stuck state: SDA stuck low vs SCL stuck low vs post-timeout “bus owned”.
- Recovery pulses: toggle SCL X times (typical 9) to release a slave state machine.
- Send STOP: emit a STOP condition (if supported) to restore a known idle state.
- Reset sequence (optional): only if line state cannot be recovered or the bridge state machine is corrupted (soft reset / re-enumerate placeholder).
- Re-accept: run a minimal transaction set (optional address probe + one known read/write) to confirm recovery.
Pass criteria (placeholders)
- Bus returns to idle (SCL=H, SDA=H) within X ms.
- Recovery success ≥ X% over X injected stuck events.
- Post-recovery minimal transaction passes X consecutive times (no NACK/timeout).
- What to verify: arbitration loss detection and a deterministic return-to-idle behavior after conflict.
- Symptom: intermittent timeouts or random NACK bursts when another master is present; bus stays “owned” after a conflict.
- First probe: inject a controlled conflict (second master START overlap) and record the bridge error signature and recovery behavior.
- Fix direction: if arbitration is not robust, treat the system as single-master and redesign ownership (outside this page).
- Pass criteria: arbitration events detected with mis-detect ≤ X%; return to idle within X ms; no cascading failures across X subsequent transactions.
SPI Bridge Deep Dive
SPI bridge reliability depends on transaction boundaries and chip-select (CS) semantics. Many devices define a transaction as “CS low until the full command/address/data sequence completes”. This section prioritizes boundary verification, then mode (CPOL/CPHA), then throughput tuning.
- Mode (CPOL/CPHA): validate Mode 0/1/2/3 against a minimal known-read (ID/status) before tuning speed.
- CS hold: ensure CS remains low across command + address + data (no split into multiple transactions).
- CS high gap: meet device-required inter-transaction gap ≥ X (placeholder) to avoid state-machine ambiguity.
- First probe: detect whether a “single API call” becomes multiple CS low-high segments due to buffering/USB packetization.
Pass criteria (placeholders)
CS is not interrupted during a transaction (success ≥ X%); CS high gap ≥ X; minimal read is stable for X consecutive cycles.
- Burst workload: measure effective throughput over X MB transfers; prioritize batching and boundary preservation.
- Small-packet workload: measure mean and tail latency (P99) over X transactions; overhead is dominated by transaction setup and CS policy.
- Fix direction: separate profiles for burst vs interactive/small-packet; do not force one configuration to serve both.
- Pass criteria: burst ≥ X MB/s (or ≥ X% of target); P99 ≤ X ms; stress duration X min with zero corruption.
Mode signature
Bit-shifted bytes, mirrored patterns, or “all 0/all 1” reads typically indicate CPOL/CPHA mismatch. First probe: validate M0..M3 against a minimal stable read.
Boundary signature
Occasional corruption, alignment drift during continuous reads, or failures that disappear at lower speed often indicate CS split/gap violations. First probe: verify CS is not fragmented by buffering.
Multi-CS and GPIO-emulated CS risks
Multiple chip selects require deterministic CS timing. GPIO-emulated CS can add jitter and non-uniform gaps; verify per-CS timing compliance and isolate transactions per device.
Scope guard: high-speed signal integrity and board-level SPI routing are handled on dedicated hardware pages; this section stays at bridge behavior and verification points.
USB↔GbE Bridge Deep Dive
A USB-to-Ethernet bridge is validated by driver binding, interface identity (MAC/EEPROM policy), and repeatable throughput/latency stability. This section focuses on “symptom → configuration → verification” without entering Ethernet PHY or magnetics design.
ECM
- Goal: minimize deployment friction using a standard USB NIC class.
- Quick check: plug-in produces a stable virtual NIC name/interface within X s.
- Pass criteria: re-plug/reboot X cycles with consistent binding and no driver re-install prompts.
NCM
- Goal: higher throughput via frame/transfer aggregation.
- Symptom: high peak throughput but occasional stalls or CPU spikes under sustained load.
- Pass criteria: throughput ≥ X Mbps with CPU ≤ X% for X min.
RNDIS
- Goal: common Windows ecosystem path where policy permits.
- Risk check: multi-OS deployment may fragment configurations and support workflows.
- Pass criteria: driver binding remains stable across updates and re-plug cycles (≤ X manual actions).
MAC identity & EEPROM policy (stable vs unique)
- Stable identity: keep MAC/interface identity consistent for predictable OS binding.
- Uniqueness: define a serial/MAC policy for production (placeholder) to avoid collisions at scale.
- Pass criteria: no MAC duplication observed across X units; identity persists after firmware/NVM updates.
Scope guard: Ethernet PHY/magnetics/EMI and cable-domain behavior are handled on dedicated Ethernet pages; this section stays at USB NIC enumeration, driver binding, and virtual interface behavior.
Throughput (TCP/UDP) — tool: iperf3
- What to do: measure both uplink and downlink; keep test duration ≥ X s.
- Symptom: TCP looks fine but UDP loss increases under load → aggregation/CPU pressure likely.
- Pass criteria: TCP ≥ X Mbps; UDP loss ≤ X% at target rate.
Latency & tail jitter — tool: ping
- What to do: record average and P99 while running a sustained throughput test in parallel.
- Symptom: average is low but P99 spikes → scheduling/aggregation interactions likely.
- Pass criteria: P99 ≤ X ms under target traffic load.
MTU path & large frames — tool: ping (size/DF)
- What to do: verify large-frame continuity at MTU = X (placeholder) without fragmentation drops.
- Symptom: default MTU passes but large MTU fails → configuration mismatch or aggregation limits.
- Pass criteria: X consecutive large-frame probes pass with zero loss.
CPU load & stability — tool: top / task manager
- What to do: record CPU while holding target throughput for X min.
- Symptom: higher throughput causes stalls/drops → CPU saturation or queue pressure likely.
- Pass criteria: CPU ≤ X% at the target throughput; no drops/resets over duration.
Branch A: USB-side event (re-enumeration)
- Symptom: virtual NIC disappears and re-appears; interface index/name changes.
- Quick check: confirm whether the device re-enumerated during the outage (event logs/USB reset indicators).
- Fix direction: prioritize board power/inrush/USB attribute consistency checks (covered in H2-10).
- Pass criteria: no unexpected re-enumeration over X h stress; recovery time ≤ X s if forced.
Branch B: Network-side event (link/config)
- Symptom: device still enumerated, but traffic stalls; DHCP fails; link toggles without USB reset.
- Quick check: interface state (up/down), IP presence, MTU consistency, and whether aggregation settings changed.
- Fix direction: revisit ECM/NCM/RNDIS choice, MTU, and CPU/queue stability targets (covered in Subcards 1–2).
- Pass criteria: under target load, no link-down events; tail latency P99 ≤ X ms.
Logging minimum (actionable only)
- Timestamp of outage start/end and whether USB re-enumeration occurred.
- Active class (ECM/NCM/RNDIS), MTU, and traffic profile during failure.
- CPU snapshot and drop counters (placeholder fields).
Signal & Power Integration (Board-Level)
Board integration should be sufficient for first-power success and stable enumeration. This section provides bring-up checklists for power, USB attribute consistency, clock stability, and interface-protection selection criteria without expanding into high-speed SI or dedicated ESD pages.
- Rails: confirm required rails are present (5V / 3V3 / 1V8 placeholders) and meet ripple ≤ X mVpp.
- Power-up: verify sequencing requirements (placeholder) and avoid partial-rail brownout during enumeration.
- Inrush: manage plug-in surge so VBUS and downstream rails do not dip beyond X mV for longer than X ms.
- Decoupling: place local capacitors at each rail pin cluster with a short return path to the reference ground.
Pass criteria (placeholders)
- No unintended resets during plug-in and sustained load for X min.
- Hot-plug success ≥ X% across X cycles.
- Bus-powered vs self-powered: descriptor declarations must match the real power topology.
- MaxPower: ensure configured MaxPower (≤ X mA) is realistic to avoid host-side policy throttling or resets.
- Suspend/wakeup (if used): validate suspend/resume stability over X cycles with no interface loss.
- NVM impact: record which NVM fields change binding behavior (VID/PID/serial/power attributes) and gate them with a rollback plan.
Pass criteria (placeholders)
Enumeration completes within X s with no over-current warnings; after X suspend/resume cycles (if applicable), the interface remains present and functional.
- Connector protection placement: place interface protection near the connector with short return to the reference ground.
- Decoupling priority: keep high-frequency decaps adjacent to power pins; avoid long vias/loops in the return path.
- Clock source: keep crystal/CLKIN routing short and away from noisy power-switching zones.
- Reference ground continuity: maintain a continuous ground reference under critical routes; avoid split-plane crossings.
- ESD selection criteria only: choose by IEC level and capacitance limits (link placeholder), not by brand tables here.
Scope guard: detailed high-speed routing/impedance/EMI and dedicated ESD part selection are handled on separate pages; this section only provides bring-up-oriented rules and pass criteria.
Note: protection devices are referenced by selection criteria only; detailed IEC waveforms, capacitance-to-signal tradeoffs, and layout proof are handled on dedicated ESD and high-speed routing pages.
Engineering Checklist (Design → Bring-up → Production)
This checklist drives a USB bridge from “it works on one bench” to “it ships, scales, and recovers safely”. Each gate includes an actionable verification method and a pass criterion placeholder.
Gate A — Driver deployment reality
- Check: target OS mix + “driver allowed?” constraint (standard class vs vendor driver).
- Method: define a deployment proof: plug-in bind behavior + replug + OS update smoke test.
- Pass criteria: binding completes within X s; manual install steps ≤ X; replug X cycles without drift.
Gate B — Interface coverage & concurrency
- Check: required interfaces (UART/I²C/SPI/GbE), multi-port needs, and required GPIO/handshakes.
- Method: define “minimum interface actions” per interface (loopback/read-ID/ping) and run under concurrency.
- Pass criteria: concurrent operation for X min with error count ≤ X (placeholder).
Gate C — NVM/EEPROM safety (anti-brick)
- Check: which fields are “safe to lock” vs “must be recoverable” (VID/PID/serial/MAC/power attributes/GPIO modes).
- Method: define a recovery path (factory default, strap pin, safe-mode, or external programming).
- Pass criteria: misconfiguration recovery time ≤ X min; recovery success rate ≥ X%.
Gate D — Identity & traceability
- Check: serial policy (placeholder), MAC uniqueness policy (if USB NIC), and configuration versioning.
- Method: log “FW version + NVM checksum + descriptor hash” (placeholder fields) per unit.
- Pass criteria: uniqueness collisions = 0 across X units; trace fields present rate ≥ X%.
Minimum logging fields
- Timestamped: plug-in, enumeration complete, first successful transaction, first failure.
- Captured: class (CDC/ECM/NCM/RNDIS), VID/PID, serial, interface count, power attributes.
- Pass criteria: logs allow failure classification within X min (enumeration vs function vs performance vs power).
Minimum functional test set
- UART: TX/RX sanity + (if required) RTS/CTS behavior check.
- I²C: scan + read/write a known register + repeated-start compatibility (if required).
- SPI: read-ID + verify CS hold/gap constraints with a single known peripheral.
- USB NIC: link up + DHCP/static + ping + short iperf3 run.
- Pass criteria: each interface passes X consecutive trials, total bring-up time ≤ X min.
Stability sanity (fast but meaningful)
- Hot-plug: X cycles with stable binding and no surprise re-enumeration.
- Sustained traffic: X min with tail latency P99 ≤ X ms (if USB NIC).
- Suspend/resume (if used): X cycles with zero interface loss.
Uniqueness & labeling
- Program: serial number policy (placeholder) and MAC policy (if USB NIC).
- Verify: no duplicates across X units; audit log includes unit ID + checksum.
- Pass criteria: duplicates = 0; trace log completeness ≥ X%.
Configuration control
- Record: FW version + NVM checksum + descriptor hash (placeholder fields) per unit.
- Lock policy: define which fields are locked at production and which remain recoverable.
- Pass criteria: station-to-station configuration mismatch rate ≤ X%.
Rollback & rework path
- Define: entry to safe mode / factory default / external programming route.
- Measure: average rework time and recovery success rate using intentionally “bad” configs.
- Pass criteria: rollback ≤ X min; success ≥ X%.
Diagnostics hooks (minimum)
- Expose: active class/config, current FW/NVM version, error counters, last reset reason (placeholders).
- Pass criteria: field incidents can be classified within X min without hardware probing.
Remote update risk control (if used)
- Pre-check: stable power + stable link + verified rollback entry.
- Pass criteria: failed updates recover within X min and do not lose identity/binding.
Applications & IC Selection Logic
Selection is a forced path: OS/deployment constraints → interface set → performance envelope → NVM safety → production plan. This section provides decision logic and a reference set of concrete material numbers (verify package/suffix/availability).
Driver strategy
- If “no installer allowed”: prioritize standard classes (CDC-ACM for UART; ECM/NCM for USB NIC where applicable).
- Pass criteria: bind within X s; manual actions ≤ X; replug X cycles stable.
Interface set & control pins
- Map tasks to interfaces: console/log (UART), register bring-up (I²C), flash/control (SPI), management tunnel (USB NIC).
- Include control pins: RTS/CTS, reset/boot, CS count, GPIO timing expectations.
- Pass criteria: concurrency X min with error count ≤ X.
Performance envelope
- Define acceptance as a set: throughput + tail latency (P99) + CPU + stability duration.
- Pass criteria: TCP ≥ X Mbps; P99 ≤ X ms; CPU ≤ X% for X h.
NVM/EEPROM capability & safety
- Require: recoverable configuration, factory-default path, and a rollback procedure before locking fields.
- Pass criteria: recovery ≤ X min; recovery success ≥ X%.
Reference material numbers (verify package/suffix/availability)
USB↔UART bridge ICs
FTDI: FT232R / FT232RL, FT231X, FT2232H, FT4232H
Silicon Labs: CP2102N, CP2104, CP2105
Microchip: MCP2221A (USB-UART + I²C)
USB↔I²C / SMBus bridge ICs
Silicon Labs: CP2112 (USB-to-SMBus/I²C)
Microchip: MCP2221A (multi-function)
USB↔SPI bridge ICs
Silicon Labs: CP2130 (USB-to-SPI)
FTDI: FT232H (multi-protocol engine; validate transaction boundaries)
USB↔GbE (USB Ethernet) bridge ICs
Microchip: LAN7800, LAN7850
ASIX: AX88179, AX88772B
Realtek: RTL8153, RTL8156
Common external NVM parts
I²C EEPROM: AT24C02, M24C02, 24LC02
“MAC-in-EEPROM” options: 24AA02E48 / 24AA02E64 (pre-programmed EUI-48/EUI-64 families; verify exact suffix)
Microwire EEPROM (common in legacy configs): 93LC46B (verify variant)
Interface protection examples (reference only)
ESD arrays (verify C & IEC level): TPD4E05U06, RClamp0504S, SP0503BAHT
Scope guard: detailed IEC waveform tradeoffs and layout proof belong on the dedicated ESD page.
Note: material numbers above are reference anchors for the selection logic. Always verify package, voltage, temperature grade, and suffix-specific features before locking a BOM.
- OS & deployment constraint: must be installer-free? driver signing allowed? policy constraints?
- Primary interface: UART vs I²C vs SPI vs USB NIC (avoid mixing until the primary path passes).
- Performance envelope: throughput + P99 latency + CPU + stability duration as acceptance set.
- NVM strategy: what must be unique, what must be recoverable, how to enter recovery mode.
- Production plan: trace fields, automated test coverage, rollback/rework SOP.
Lock criteria (placeholders)
Lock the device class/capability set only after: stable binding over X replug cycles, stable performance for X h, and verified recovery/rollback within X min.
Wrong: vendor-driver dependency in a locked-down environment
Symptom: devices enumerate but cannot be used without installs; deployment becomes the bottleneck. Avoid at decision step #1. Pass criteria: install steps ≤ X, policy compliance verified.
Wrong: irreversible NVM field lock
Symptom: one bad programming batch turns into rework/returns (“bricked” units). Avoid at decision step #4. Pass criteria: recovery ≤ X min, success ≥ X%.
Wrong: chasing peak throughput only
Symptom: good averages but poor tail latency and intermittent stalls under load. Avoid at decision step #3. Pass criteria: P99 ≤ X ms with CPU ≤ X%.
Wrong: missing MAC/serial uniqueness plan (USB NIC)
Symptom: duplicate identities create DHCP conflicts and remote management confusion. Avoid at decision step #4–#5. Pass criteria: duplicates = 0 across X units.
Recommended topics you might also need
Request a Quote
FAQs
Troubleshooting is kept compact: each answer provides an executable first check, a minimal fix path, and quantified pass criteria (threshold placeholders).
Device shows up as “Unknown USB Device” after EEPROM change — what’s the first rollback step?
Likely cause: USB descriptors became invalid (VID/PID/config/power fields), so enumeration fails before any function loads.
Quick check: Force the bridge into factory/safe mode (strap/button, if available) or bypass the external EEPROM/NVM (if the design supports boot-with-defaults); retry with a known-good cable/host port.
Fix: Re-flash a known-good “MVP descriptor image” first (only essentials), then re-apply optional fields incrementally; keep a recovery path (factory image / safe strap / external programmer) for future updates. (External I²C EEPROM examples: AT24C02 / M24C02 / 24LC02 — verify variant.)
Pass criteria: Enumerates with correct VID/PID within X s; replug X cycles with zero “Unknown device”; recovery success rate ≥ X%.
CDC works on Linux but not on Windows — first “driver binding” check?
Likely cause: Windows binds to the wrong interface (composite/IAD mismatch) or the CDC interface does not match Windows’ expected descriptor pattern.
Quick check: On Windows, confirm which driver is bound to each interface (Device Manager → hardware IDs); verify the CDC-ACM interface class/subclass/protocol and interface numbering match what Windows expects.
Fix: Correct descriptors (add/repair IAD for composite CDC if needed), keep VID/PID and interface layout stable, and use a signed INF only if policy allows; avoid mixing optional functions that change interface ordering.
Pass criteria: Windows auto-creates a COM port within X s on X Windows builds; manual steps ≤ X; binding remains stable across X reboots.
Multiple identical bridges: ports swap order randomly — how to enforce stable identity?
Likely cause: Missing or duplicated serial number / identity fields cause the OS to assign ports based on discovery order.
Quick check: Read iSerialNumber (and for USB NIC: MAC) on each unit; replug in different order and cold-boot to see whether mapping changes.
Fix: Program a unique serial number per unit; for USB↔GbE, enforce unique MAC (e.g., pre-programmed EUI EEPROM families such as 24AA02E48/24AA02E64 — verify exact suffix); keep interface numbers stable across firmware/NVM revisions.
Pass criteria: Port mapping remains stable across X cold boots and X replug cycles; uniqueness collisions = 0 in a batch of X units.
UART terminal feels laggy though baud is low — which latency timer/buffer setting first?
Likely cause: USB-side packetization buffers small UART bursts until a latency timer expires, creating visible interactive delay.
Quick check: Measure character-to-echo latency (scripted loopback) and then reduce the driver “latency timer” (or enable low-latency mode) without changing baud.
Fix: Set latency timer to X ms (start low, then back off if CPU rises), tune read/write buffer sizes, and avoid aggressive USB selective-suspend for interactive consoles.
Pass criteria: Round-trip latency P95 ≤ X ms over X min; no missing characters over X characters; CPU ≤ X% during the test.
RTS/CTS wired but flow control still overruns — first electrical vs driver sanity check?
Likely cause: Hardware flow control is not enabled in the driver/application, or the handshake lines have polarity/level issues.
Quick check: Toggle RTS in software and observe CTS response on a scope/logic analyzer; confirm the port is configured for RTS/CTS (not XON/XOFF) end-to-end.
Fix: Enable hardware flow control explicitly, correct wiring/polarity, and ensure voltage levels meet the bridge IO spec; if needed, reduce baud or increase buffers until the electrical layer is corrected.
Pass criteria: Overrun/error count ≤ X per X MB; CTS response time ≤ X µs; sustained transfer X min without framing/overrun errors.
I²C reads hang intermittently — how to distinguish pull-up/cap loading vs clock-stretch incompatibility?
Likely cause: Slow edges from weak pull-ups/high bus capacitance, or a clock-stretch/repeated-start behavior mismatch between bridge and target.
Quick check: Scope SDA/SCL rise time and retry at a lower I²C speed; then re-test with clock-stretch disabled/enabled (or a longer stretch timeout) to see which change eliminates the hang.
Fix: Adjust pull-ups to meet a rise-time target (placeholder), reduce bus capacitance (shorter run / fewer loads), and set the bus to X kHz if required; ensure stretch/repeated-start compatibility matches the target’s needs.
Pass criteria: X transactions without hang at X kHz; rise time ≤ X ns; timeout/NAK error count ≤ X over X min.
I²C bus stuck low — fastest recovery pulse sequence and pass criteria?
Likely cause: A slave is holding SDA low after a partial byte/ACK phase, often triggered by resets/brownouts mid-transaction.
Quick check: Confirm whether SDA or SCL is stuck low; if SDA is stuck, attempt recovery without power-cycling by issuing SCL pulses while sampling SDA.
Fix: Drive 9–16 SCL toggles (at a safe low rate) until SDA releases, then issue a STOP (SDA low→high while SCL high); if still stuck, reset/power-cycle the target or isolate the segment and retry.
Pass criteria: SDA and SCL return high within X ms; subsequent X read/write operations succeed; stuck-low recurrence ≤ X per X h.
SPI works at low speed but fails at higher — first check CS timing or clock edge (CPHA/CPOL)?
Likely cause: At higher SCLK, CPOL/CPHA mismatch or insufficient CS setup/hold becomes visible; signal integrity margins shrink.
Quick check: Lock the peripheral to a known SPI mode (0/1/2/3) and then add explicit CS setup/hold and inter-transaction gaps; observe SCLK/MISO/MOSI/CS at the failing speed.
Fix: Set correct CPOL/CPHA, enforce CS setup ≥ X ns and hold ≥ X ns, and reduce SCLK to X MHz if needed; consider small series resistors on fast edges (value placeholder).
Pass criteria: X consecutive transfers succeed at target speed; error rate ≤ X per X MB; measured CS/setup/hold meet thresholds.
SPI peripheral ID reads right once then wrong — transaction boundary/CS hold issue?
Likely cause: The bridge is not enforcing transaction boundaries (CS does not toggle as the peripheral expects), causing command/response alignment loss.
Quick check: Force CS high between commands and add a fixed inter-command gap; compare the first “good” waveform to subsequent “bad” cycles.
Fix: Configure the bridge to treat each command as an atomic frame (CS toggle per frame), add CS high gap ≥ X µs, and clear RX buffering between transactions if supported.
Pass criteria: ID is consistent across X consecutive reads; no desync over X min stress; CRC/checksum errors = 0 (if applicable).
USB↔GbE throughput unstable — first check driver mode (ECM/RNDIS/NCM) or MTU/offload?
Likely cause: Mode mismatch and host-stack behavior (ECM vs NCM vs RNDIS) or MTU/offload settings cause burstiness, drops, or periodic stalls.
Quick check: Confirm negotiated USB speed (HS vs SS) and active NIC mode; run iperf3 at fixed MTU and compare “offload ON vs OFF” while watching CPU and packet drops.
Fix: Use the preferred mode per OS policy (ECM/NCM typically for class-based paths; RNDIS only where required), set MTU to X (e.g., 1500/9000 as a validated profile), disable problematic offloads, and ensure power headroom under load.
Pass criteria: Throughput ≥ X Mbps with stddev ≤ X% over X min; packet loss = 0; no link resets over X h.
Device enumerates but drops under load — power attribute mismatch or inrush/brownout?
Likely cause: Brownout from inrush/load steps or a mismatch between declared MaxPower and real consumption triggers resets or re-enumeration.
Quick check: Scope/log VBUS and core rails during the failure; compare descriptor MaxPower vs measured draw; repeat using a powered hub and a short cable.
Fix: Align power attributes with reality, add VBUS bulk capacitance (value placeholder) and inrush control, ensure regulator headroom and decoupling meet load transient needs, and address thermal limits if the drop correlates with temperature.
Pass criteria: Zero disconnects over X min stress; VBUS droop ≤ X mV; core rail minimum ≥ X V; re-enumeration events = 0.
Firmware upgrade tool loses connection mid-flash — how to set “safe mode” and pass criteria?
Likely cause: The device resets or re-enumerates during flash without a stable bootloader identity, or power dips interrupt programming.
Quick check: Verify whether VID/PID or interface layout changes during update; confirm a deterministic recovery entry (strap/button/command) exists and works when the main firmware is corrupted.
Fix: Use a two-stage bootloader with a fixed “safe mode” identity, chunked writes with acknowledgements, and a rollback image; require stable power for the update and keep an emergency recovery route (safe strap / external programmer / known-good EEPROM image).
Pass criteria: Upgrade success rate ≥ X% over X attempts; failed upgrades are recoverable within X min; device identity remains stable across upgrade and reboot X times.
