Electronics Design AU
Communications

USB

USB protocol design: USB-C, USB PD, USB Full Speed and High Speed, device and host mode, and embedded USB implementation.

USB is the connector most embedded products end up needing (for firmware updates, serial debug consoles, host communication, or bus power), and it is also one of the more failure-prone interfaces to get right the first time. This subtopic covers USB at the practical implementation level: PCB design for USB-C, enumeration debugging, and Power Delivery. For USB's protocol fundamentals (descriptor hierarchy, device classes, host/device topology), see What Is USB? in the parent Communications topic.

What Does USB Implementation Cover?

Beyond the protocol fundamentals, building USB into a product involves:

  • PCB-level design — CC resistor configuration for USB-C, differential pair impedance and routing, ESD protection placement, and VBUS decoupling.
  • Enumeration correctness — the device/configuration descriptor content, VID/PID assignment, clock accuracy, and pull-up timing that determine whether a host recognises the device at all.
  • Power Delivery — negotiating voltages above the 5 V default via a PD controller IC, and rating the downstream power path for whatever voltage the design will actually request.
  • Version and PHY selection — choosing between USB 2.0, USB 3.x, and USB4 based on genuine bandwidth need rather than defaulting to the newest standard.
  • Dual-role (OTG) design — building a product that can act as either a USB host or a USB peripheral, including ID-pin/CC-line role detection and host-mode VBUS power.

Why USB Implementation Matters

  • A USB-C port with no CC pull-downs won't power up at all — modern USB-C sources will not supply VBUS current to a device without the correct CC resistor configuration signalling its power role; this is a common first-prototype bring-up failure, not an edge case.
  • Enumeration failures are opaque from the host side — "Unknown USB Device" or a driver installation failure gives almost no information about which of several possible root causes is responsible, without a protocol analyser capturing the actual descriptor exchange.
  • Power Delivery mistakes can exceed a rail's rated voltage — if the downstream buck/boost converter isn't rated for the maximum voltage a PD controller can negotiate (9 V, 12 V, 15 V, 20 V), a source that offers a higher profile than expected can damage the product.
  • Choosing USB4 or USB 3.x without a real bandwidth need adds unjustified PHY complexity — most embedded microcontroller applications (CDC-ACM serial, HID, DFU) need only USB 2.0's two-wire differential pair, which the overwhelming majority of MCUs support natively.

Key Concepts

  • CC1/CC2 (Configuration Channel) — the USB-C pins used for cable orientation detection, power role signalling (via pull-up/pull-down resistor values), and USB PD communication when a PD controller is present.
  • VID/PID (Vendor ID / Product ID) — the 16-bit identifiers reported in the device descriptor that the host OS uses to select a driver; a VID/PID that collides with another device's registered driver causes enumeration to fail or attach the wrong driver.
  • Enumeration — the sequence of standard requests (GET_DESCRIPTOR, SET_ADDRESS, SET_CONFIGURATION) a host issues after device attach to identify and configure a USB device before it becomes usable.
  • PDO (Power Data Object) — a USB PD source's advertised voltage/current profile; a PD sink negotiates the best matching PDO from the set the source offers.
  • Full Speed vs High Speed — USB 2.0's two device speed classes (12 Mbit/s and 480 Mbit/s respectively); most MCU USB peripherals support one or both, with High Speed requiring a more accurate 48 MHz clock reference.

Common Mistakes

  • Omitting CC pull-down resistors on a device-only USB-C port — without 5.1 kΩ pull-downs on CC1 and CC2, a USB-C source will not apply VBUS, and the port appears completely dead. See USB-C PCB design for the full CC configuration.
  • Debugging enumeration failures from host-side symptoms alone — "Unknown USB Device" has at least five distinct root causes; without a USB protocol analyser capturing the actual descriptor exchange, debugging becomes guesswork. See USB enumeration failing.
  • Rating the downstream power path for only the default 5 V — a PD-negotiated rail can reach 20 V; the buck/boost converter and downstream components must be rated for the maximum voltage the design's PDOs allow, not just the default.
  • Defaulting to USB 3.x or USB4 without a bandwidth requirement — the added PHY complexity, connector requirements, and MCU/companion-chip cost are not justified for CDC-ACM serial, HID, or firmware update use cases that USB 2.0 handles natively on nearly every MCU with integrated USB.

Common Questions

Does every USB-C device need a PD controller IC?

No. A device that only needs the default 5 V at up to 900 mA (USB-C's default current allocation without PD negotiation) needs only the 5.1 kΩ CC pull-down resistors, and no PD controller IC is required. A PD controller becomes necessary only when the product needs a higher voltage (9 V, 12 V, 15 V, 20 V) or higher current than the default USB-C allocation provides. See USB Power Delivery implementation for the controller options and when each applies.

Why does my USB device enumerate on one computer but not another?

This usually points to marginal timing or signal integrity that a more tolerant host stack accepts and a less tolerant one rejects: clock accuracy near the ±0.25% Full Speed tolerance boundary, a D+ pull-up with borderline timing, or a differential pair with impedance discontinuities that only some host controllers are sensitive to. It can also indicate a VID/PID conflict with a driver already installed on one machine but not the other. Capture the enumeration sequence with a USB protocol analyser on both the working and failing host to compare where the sequences diverge. See USB enumeration failing for the full diagnostic approach.

What USB version should I target for a typical embedded product?

USB 2.0 Full Speed or High Speed, for the large majority of embedded products: CDC-ACM virtual serial ports, HID devices, firmware update (DFU) interfaces, and most sensor or instrument products. USB 3.x is justified only when the product genuinely moves bulk data (cameras, external storage, high-bandwidth streaming sensors); USB4 is essentially out of scope for MCU-based embedded design. See USB 2.0 vs USB 3.x vs USB4 for the full comparison. Zeus Design designs USB-C hardware and firmware, including Power Delivery, for embedded products.

Knowledge Base

PCB Design

  • How Do You Design a USB-C Port on a PCB? — CC resistors for UFP/DFP roles, ESD protection IC selection and placement, D+/D– differential pair impedance, VBUS decoupling, and USB Power Delivery basics

Firmware and Descriptor Design

Debugging

Power Delivery

Host and Device Roles

Standards and Version Selection

Isolation

Forum Discussions

Forum Discussions

Related Topics