• 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%.

• 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.

• 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.

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.

The MVP keeps enumeration and binding deterministic while allowing limited tuning for interactive debug.

• 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).

• 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).

• 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.

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.

1. Freeze new transactions: stop issuing new I2C operations to avoid compounding errors.
2. Classify the stuck state: SDA stuck low vs SCL stuck low vs post-timeout “bus owned”.
3. Recovery pulses: toggle SCL X times (typical 9) to release a slave state machine.
4. Send STOP: emit a STOP condition (if supported) to restore a known idle state.
5. Reset sequence (optional): only if line state cannot be recovered or the bridge state machine is corrupted (soft reset / re-enumerate placeholder).
6. Re-accept: run a minimal transaction set (optional address probe + one known read/write) to confirm recovery.

• 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.

• 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.

• 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.

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.

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.

• 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.

• 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.

• 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.

1. OS & deployment constraint: must be installer-free? driver signing allowed? policy constraints?
2. Primary interface: UART vs I²C vs SPI vs USB NIC (avoid mixing until the primary path passes).
3. Performance envelope: throughput + P99 latency + CPU + stability duration as acceptance set.
4. NVM strategy: what must be unique, what must be recoverable, how to enter recovery mode.
5. Production plan: trace fields, automated test coverage, rollback/rework SOP.