How Do You Implement USB Power Delivery in an Embedded Product?

Detailed Explanation

USB PD lets an embedded product draw meaningfully more power than default USB current limits allow — up to 240 W under USB PD 3.1's Extended Power Range — but implementing it correctly requires understanding that PD negotiation is a protocol running on the CC lines, entirely separate from the D+/D– data lines and the basic CC pull-down resistors used for simple 5 V sink identification. For the CC-line hardware fundamentals below PD negotiation, see How Do You Design a USB-C Port on a PCB?; for USB protocol context generally, see What Is USB?.

Why CC Pull-Downs Alone Aren't Enough

A UFP (device) with simple 5.1 kΩ pull-downs on CC1 and CC2 identifies itself to the host as a power sink and can draw the USB specification's default current (500 mA at USB 2.0, 900 mA at USB 3.x) at the standard 5 V. This is genuinely sufficient for many low-power embedded products. USB PD negotiation — requesting a different voltage, or more current at 5 V than the default — requires bidirectional communication over the CC line using the USB PD protocol's BMC (Biphase Mark Coding) signalling, which a simple pull-down resistor cannot generate or interpret. This is why a PD controller IC, not just passive CC resistors, is required the moment a design needs anything beyond default USB power.

Two Common Implementation Approaches

Autonomous sink controller (STUSB4500): the controller stores up to three PDO requests in on-chip NVM, handles the entire PD negotiation handshake independently of the host MCU, and simply asserts the negotiated voltage on its output once complete — exposing status and configuration over I2C for monitoring or runtime adjustment, but requiring no PD protocol stack running on the host processor at all. This is the simpler path for a product that needs a fixed target voltage (e.g. always request 12 V if available, falling back to 5 V) without dynamic negotiation logic.

Firmware-driven controller (FUSB302): the controller exposes low-level PD protocol primitives over I2C, and a PD protocol stack (either a vendor-provided library or an open-source implementation) running on the host MCU handles message parsing, PDO evaluation, and Request message generation. This path is necessary when the negotiation logic needs to be dynamic — for example, requesting a different PDO based on the product's operating mode, or implementing more complex USB PD features (alternate modes, extended messages) beyond simple power negotiation.

For most embedded products that simply need "5 V default, or 9 V/12 V/15 V/20 V if available, pick the best one automatically," the autonomous approach (STUSB4500 or equivalent) is the lower-firmware-effort choice. Firmware-driven negotiation is justified when the product's power requirements genuinely change based on runtime state.

PDOs and the Negotiation Sequence

A PDO (Power Data Object) is a single voltage/current/power combination a source advertises — a typical PD charger might offer PDOs for 5V/3A, 9V/3A, 15V/3A, and 20V/5A. The negotiation sequence: the source broadcasts a Source_Capabilities message listing all its PDOs; the sink evaluates them against its own configured requirements (whether via NVM-stored preference on an autonomous controller, or firmware logic on a host-driven design) and sends a Request message selecting one; the source responds with Accept and then PS_RDY once its output has actually transitioned to the requested voltage — the sink must wait for PS_RDY before assuming the new voltage is present and stable, not just after sending the Request.

Designing the Downstream Power Path

The PD controller only negotiates the input voltage; the product's actual power rails still need conversion from whatever voltage was negotiated. This has a direct hardware consequence: every component between the USB-C connector and the point of final regulation must be rated for the maximum voltage the design will ever request, not the default 5 V. See DC-DC converter topology selection for choosing the downstream regulator topology, and how does a buck converter work? for the conversion stage itself if stepping down from a higher negotiated voltage (9–20 V) to the product's internal rail (commonly 3.3 V or 5 V).

Design Considerations

• Rate every component in the power path for the maximum PDO you'll request, not the default 5 V. VBUS decoupling capacitors, protection diodes, and the input side of the downstream regulator all need headroom above the highest voltage the design negotiates — this is the same VBUS-rating principle covered for basic USB-C design, extended to the full PD voltage range.
• Choose autonomous vs firmware-driven based on whether negotiation logic genuinely needs to be dynamic, not by default — the autonomous approach meaningfully reduces firmware scope and bring-up complexity for fixed-target designs. Zeus Design designs USB PD power architectures — both hardware and firmware — for products with elevated power requirements beyond default USB current.
• Wait for PS_RDY before assuming the negotiated voltage is present, not just after sending the Request message — the source needs time to actually transition its output, and downstream circuitry that assumes the new voltage immediately can misbehave during that transition window.
• Confirm your target charger/source ecosystem's actual PDO offerings before finalising a target voltage. Not every USB PD source offers every possible voltage tier — a design expecting to always find a 20 V PDO available should have a sensible fallback behaviour (e.g. 5 V default operation) for sources that don't offer it.

Common Mistakes

• Rating VBUS-adjacent components only for 5 V on a design that will request higher PD voltages, producing an overvoltage failure the first time the device connects to a charger that grants the higher-voltage PDO.
• Assuming a Request message alone means the new voltage is present. The actual voltage transition happens between Accept and PS_RDY; downstream logic that switches operating modes immediately after sending the Request rather than after receiving PS_RDY can act on stale voltage assumptions.
• Choosing a firmware-driven PD controller (FUSB302) for a design with genuinely fixed power requirements, taking on unnecessary firmware development and protocol-stack maintenance when an autonomous controller (STUSB4500) would meet the same requirement with far less firmware scope.
• Writing a custom PDO to the STUSB4500's working registers without committing it to NVM. The working registers apply immediately and make bring-up look correct, but they're RAM-backed and revert to whatever's stored in NVM on the next power cycle — see this NVM-vs-working-register bring-up thread for the full unlock/erase/program/verify sequence required to make a profile persist.
• Not planning for sources that don't offer the desired PDO. A design hard-coded to request a specific voltage with no fallback behaviour will fail to power up correctly, or behave unpredictably, when connected to a charger that doesn't offer that exact PDO.
• Confusing USB PD negotiation with the CC pull-down resistors used for basic UFP identification. These solve different problems — pull-downs identify a device as a sink at default current; PD negotiation is an active bidirectional protocol requiring dedicated controller hardware.