Troubleshooting USB-C Power Delivery: A Practical Oscilloscope Guide to PD Signals

USB-C Power Delivery (PD) is a powerful, flexible way to negotiate voltage and current between devices. But when things don’t work as expected—whether you’re designing a PD-capable charger, a device powered by USB-C, or simply debugging a failing cable—having a practical approach to observe PD signals with an oscilloscope can save hours of guesswork. This guide walks you through the key signals, measurement setup, and troubleshooting workflows you can apply with a standard bench oscilloscope. Whether you’re chasing a no-charge condition, a stuck 5 V result, or a flaky higher-voltage negotiation, you’ll come away with actionable steps and concrete waveform interpretation tips.

Understanding the basics: what you’re looking for on the PD highway

USB-C PD negotiation relies on two main domains on the physical side: the CC lines and the VBUS delivery pathway. The PD communication actually travels over the CC lines (CC1/CC2) using a low-speed signaling protocol, while VBUS carries the actual power after a successful negotiation. A PD-capable source advertises its capabilities via Rp resistors on the CC line(s), and a sink advertises its needs via Rd resistors. When PD negotiation begins, devices exchange PD messages that control voltage and current levels, VCONN usage, and the PD contract itself.

Key signals you’ll observe with an oscilloscope include:

• CC1 and CC2 lines: The primary channels for detecting orientation and negotiating PD parameters. Observe whether a device presents Rp, a sink presents Rd, and how the CC pins toggle during negotiation.
• VBUS: The supply line that ramps up once the PD contract is established. You’ll often watch the voltage rise from 0 V to the negotiated level (5 V, 9 V, 15 V, up to 20 V in some configurations).
• VCONN (when used): A separate supply line that may power electronics in the cable or an accessory. Only present in certain configurations and with appropriate devices.
• PD traffic signals on CC: The low-speed PD data stream that negotiates the contract. These are not “USB data” signals; they’re a dedicated PD protocol carried on CC via a signaling scheme called BMC (Biphase Mark Code) and interpreted by the PD controllers at each end.

In practice, you’ll be looking for a few telltale waveform patterns:

• A stable Rp or Rd state on CC when no PD talk is happening, reflecting the device’s intent to advertise power or sink power
• During negotiation, bursts of activity or toggling on CC lines as PD messages are exchanged
• A clean VBUS ramp once a contract is accepted, followed by stable VBUS at the negotiated level
• On failure, a lack of expected PD chatter, an incorrect VBUS ramp, or a stall in the negotiation (e.g., Source capabilities seen but no Request/Accept sequence)

Note: PD is designed to be robust in noisy environments and across cables of varying quality. However, a lot of the troubleshooting boils down to confirming that the signaling on CC is correct, the VBUS behavior follows a valid contract, and there are no hardware faults in the PD controller, cable, or sink/source path.

Measurement setup: what you need and how to connect

A practical oscilloscope-based PD troubleshooting setup isn’t about a dozen exotic probes; it’s about using a handful of reliable tools with proper probing technique. Here’s a checklist to get you started:

• : Any modern digital oscilloscope with at least 1 GSa/s sampling rate is fine for basic PD work; more sampling rate improves your chance to visually separate edge transitions in the PD signaling.
• Passive 10x probes for CC lines and VBUS. Use the 10x setting to minimize loading and preserve signal integrity.
• Differential probing option for CC1/CC2 if your oscilloscope supports it. A differential approach helps when measuring CC lines relative to ground in a system where ground potential differences exist.
• on VBUS to observe current draw and ensure the source delivers as negotiated.
• : Keep probe grounds short and close to the reference ground on each port. Nightmarish ground loops are a common source of misleading results in PD tests.
• : If possible, use a PD-capable source (power supply or evaluator board) and a PD-capable sink (device under test) so you can validate end-to-end behavior. A PD protocol analyzer or specialized PD sniffing tool can greatly simplify decoding, but it’s not strictly necessary for waveform diagnosis.

Important safety note: PD can deliver up to 20 V and 5–6 A depending on the role and negotiated contract. Be mindful when probing, especially with live VBUS. Use proper PPE and avoid shorting any lines during measurement. If in doubt, power down and discharge capacitors before touching leads.

Setup steps: baseline, orientation, and the first checks

Before chasing a specific fault, establish a reliable baseline and confirm that basic electrical presence is correct. Here’s a practical sequence you can follow:

1. Verify cable and connector condition: A damaged cable or bad connector is a frequent source of PD negotiation failures. Inspect for bent pins, torn shield, or excessive flexing. Replace cables if in doubt.
2. Connect a known-good PD source and sink: Start with a simple 5 V, 0.5–3 A negotiation as a baseline. This ensures that your measurement setup can observe a normal PD handshake.
3. Probe CC lines with care: Place a 10x probe on CC1 and CC2 (one at a time, depending on orientation). You should be able to see Rp on a Source or Rd on a Sink when nothing else is negotiating yet.
4. Probe VBUS with care: Put a probe on VBUS after the PD handshake is complete. Observe the voltage ramp and stability once the contract is established.
5. Set safe triggers: Use edge or slope triggers to catch PD state transitions on CC lines. For VBUS, trigger on the rising edge to capture ramp timing.

With baseline confirmed, you’ll now be prepared to identify when something is off and where to focus your investigation.

Workflow: step-by-step PD troubleshooting with an oscilloscope

The following workflow is designed to help you diagnose common PD issues using real-world waveform observations. Adapt the steps to your specific hardware and PD controller family, as some vendors implement PD signaling timing or messaging differently.

1) No PD communication: is the CC line doing its job?

Symptoms

• VBUS appears at 5 V (or some devices default to 0 V) but no negotiation occurs.
• CC lines show only a static state (no chatter, only a fixed Rd or Rp or no recognizable signal).

What to check

• Confirm orientation and CC pin usage. If you expect a Source to advertise Rp, verify which CC pin is active for the current orientation.
• Verify Rd presence on the Sink when you connect. If Rd isn’t visible, the device may be in a non-PD mode, or the line may be damaged.
• Probe the Rp values on the Source side. If you can access them, you should observe a resistor network that biases CC toward VBUS. A miswired Rp or a short to ground on CC will prevent proper negotiation.

What you might see on the scope

• CC lines hovering near a mid-level voltage or near ground with little or no activity
• VBUS ramp occurs but stops short of the expected negotiated level (often a sign that PD negotiation never completed)

Actionable steps

• Check cable orientation and try the other CC pin (rotate the plug). Some devices negotiate differently depending on orientation due to the CC multiplexing.
• Inspect the PD controller configuration on the source and sink boards. Make sure the devices are not in a non-PD fallback state (some microcontroller firmware defaults to “not powered by PD”).
• Isolate the PD path from the USB data path to ensure there are no shorts or cross-talk that might confuse the PD controller.
• If possible, test with a PD sniffer or protocol analyzer to confirm whether PD messages are emitted and if a data link layer message flow occurs.

2) PD negotiation starts but fails to complete: watching the handshake

Symptoms

• On CC, you observe short bursts of activity around the time the device should begin the handshake, but then the signals cease and VBUS does not ramp beyond a baseline level.

What to check

• Source capabilities: is the source advertising valid voltages and current limits (e.g., 5 V, 9 V, 15 V, 20 V with respective current ratings)?
• Sink requests: is the sink sending a correct Request message with the appropriate voltage/current? A malformed request can halt the negotiation.
• Cable and connector integrity: a damaged cable can distort the signaling enough to kill the handshake.

What you might see on the scope

• PD “handshake” bursts on CC that peter out before a formal Accept is seen by the Source
• Transient spikes on VBUS with no sustained ramp beyond a small initial level

Actionable steps

• Verify that the source’s Rp values are correct for the advertised current capability. If Rp is too high or too low for the desired contract, negotiation may fail or select an unsupported profile.
• Check for proper Rd resistance on the Sink. An Rd that’s too high or too low can cause negotiation failures or false disconnects.
• Test with a known-good controller or an evaluation board to isolate whether the issue is on the PD protocol layer or the physical layer (ppb of the physical line, ESD protection, etc.).

3) The contract is negotiated but VBUS does not ramp or is unstable

Symptoms

• PD signaling completes, but VBUS stays at 5 V or ramps partially and then collapses, or shows significant ripple/overshoot.

What to check

• Inspect the VBUS path: are there series resistors, fuses, or protection devices that could be constraining current or causing voltage drop?
• Confirm the source’s capability and the cable’s loss characteristics. Long or poor-quality cables increase voltage drop at higher currents and voltages.
• Check power delivery negotiation timing: ensure that the contracted voltage/current is actually being applied by the source controller, not only announced.

What you might see on the scope

• Slow or incomplete voltage ramp on VBUS
• Post-connection VBUS at a lower voltage than negotiated, or frequent oscillations around the target voltage

Actionable steps

• Try a different cable, ideally Category USB-C PD-rated, to rule out the cable as the source of the problem.
• Inspect the VBUS protection network (PTC fuse, TVS diode, current-limiter) for faults or incorrect values.
• Verify the PD controller firmware or configuration on the source. Some implementations require a particular sequence to apply the new VBUS after a negotiation.

4) Orientation-sensitive issues: CC1 vs CC2

Symptoms

• One orientation negotiates correctly while the other does not, or only works when the cable is rotated.

What to check

• Confirm CC pin mapping and whether the device under test uses CC1 or CC2 for Rd/Rp depending on orientation. Some devices rely on a deterministic CC pin for the negotiation path.
• Check the cable’s wiring for symmetry. An asymmetric cable might carry CC signals better in one orientation than the other.

What you might see on the scope

• Successful negotiation on one CC line with no sign of activity on the other
• Complete lack of PD chatter on the CC line that is not active in the current orientation

Actionable steps

• Test with a cable known to have good CC wiring on both lines. If the problem follows the cable orientation, suspect a cable fault.
• Ensure your PD controller supports CC multiplexing properly so that it engages the correct CC line when orientation changes.

5) Noise and EMI concerns: diagnosing a noisy PD path

Symptoms

• PD communication is erratic or sporadic, with occasional successful and failed negotiations.

What to check

• Probe shielding and ground loops. Ensure your scope ground reference is tied to the same ground as the PD path’s reference.
• Inspect nearby high-frequency switching supplies or motors that might inject noise into the CC lines or VBUS path.
• Check for ESD protection components that could be intermittently clamping or distorting PD signals.

What you might see on the scope

• Spikes or bursts on CC during negotiation.
• VBUS voltage jitter during the ramp or steady-state operation.

Actionable steps

• Increase decoupling and place ferrite beads near PD controllers to reduce EMI coupling.
• Run a separate power supply for the PD source to minimize ground noise.
• Consider shielding the PD controller board or re-routing sensitive traces away from noisy power planes.

6) When to rely on a PD protocol analyzer vs. an oscilloscope only

While a scope is excellent for visualizing waveforms and timing, analyzing the actual PD payloads (like Source Capabilities, Request, Accept, and GoodCRC messages) typically requires a PD protocol analyzer or a software-based decode tool. A PD analyzer can translate the CC signaling into human-readable PD messages, helping you confirm whether:

• The Source advertised the expected voltage/current levels
• The Sink sent a coherent Request with the correct parameters
• Accept/Reject messages were properly exchanged and the VBUS ramp followed the contract

How you can work with both tools

• Use the oscilloscope to validate timing, edge transitions, and the physical presence of VBUS. Then feed the CC line signals into a PD analyzer to confirm the message sequence.
• If you don’t have a dedicated PD analyzer, you can rely on documentation from the PD controller vendor and the USB-IF specification to interpret decoded patterns from the raw CC signals. This can be more challenging but is doable with careful waveform captures.

Probe technique: getting clean, informative traces

Probing PD signals requires careful technique to avoid influencing the very signals you’re trying to measure. Here are practical tips to improve signal fidelity and interpretability:

• Keep both CC lines and VBUS probes in 10x mode for reduced probe loading. If you must use 1x on CC for some reason, be aware you’ll load the line more and potentially influence the signal.
• If you’re comfortable with differential probes, measuring CC1 and CC2 differentially can help when there’s a lot of common-mode noise or ground offset between test points.
• Route grounds as short as possible, and use ground springs or small, low-inductance ground clips to reduce stray inductance and ringing on fast transitions.
• If you’re using a bench supply and a PD source, keep them physically separate from the PD data path to minimize cross-coupling.
• Overshoot on VBUS can indicate insufficient decoupling or a mis-specified protection network. If you see overshoot beyond the negotiated level, inspect the output capacitor bank and any surge protection devices.
• PD negotiations can be quick, but you’ll want long enough capture windows to observe the entire handshake and any slow ramps in voltage or current. A few milliseconds at least can be very informative.

Interpreting common PD waveform patterns: a quick reference

While every PD implementation has some variation, certain patterns tend to recur. Here’s a concise map to help you translate what you see on the screen into a probable cause:

• Likely issue with CC negotiation path (missing Rp/Rd on the right line, a miswired CC, or PD controller not enabled).
• Normal negotiation process; watch for a successful Accept and a final VBUS ramp to the target voltage.
• Might indicate protection circuitry, a high ESR in the supply or capacitors, or current-limit behavior on the source.
• Likely a CC multiplexing or cable wiring issue; test with another cable or re-examine the orientation logic in the PD controller.
• EMI or grounding issue affecting the signaling path; address shielding and grounding first.

Practical safety and best practices

PD hardware can be robust, but you’re dealing with real power levels. Here are best practices to stay safe and productive:

• Always discharge VBUS before touching hardware. Use a controlled discharge or a resistor to clamp VBUS when you’re swapping boards or cables.
• Use proper eye protection if you’re testing high-current configurations or high-VBUS conditions.
• Be mindful of hot pluggability. PD devices can briefly experience high inrush or switching spikes when a new contract is applied. Make sure your probes and devices tolerate these transients.
• Document your test setups and settings. PD behavior can be sensitive to firmware versions, cable lots, or board revisions. Keeping a test log helps reproduce problems or explain findings to teammates.

Putting it all together: a practical PD troubleshooting checklist

Use this concise checklist to quickly structure your PD debugging sessions with an oscilloscope:

1. Verify physical layer basics: cables, connectors, and mechanical integrity.
2. Confirm orientation behavior by testing both CC1 and CC2 lines with the same source and sink pair.
3. Measure CC lines for Rp/Rd presence and stability when idle and during attempts to negotiate.
4. Observe VBUS for a clean ramp to the negotiated voltage; check for overshoot, undershoot, and settling time.
5. Record PD transaction timing: Source Capabilities, Request, Accept/Reject, and GoodCRC messages if you can decode them (with a protocol analyzer or software tool).
6. Rule out EMI and grounding issues by checking noise levels and ensuring solid probe grounding.
7. If available, use a PD protocol analyzer to decode the message sequence and confirm contract validity.
8. Document failure modes and reproduce steps to help engineering teams identify root causes.

Case study: a real-world debugging scenario

Scenario: A laptop with a USB-C PD charger sometimes refuses to charge above 5 V, even though the charger advertises up to 20 V. An oscilloscope is used to inspect the CC lines and VBUS while plugging the charger into the laptop.

What you’d do and what you’d expect to see:

• Baseline: With no negotiation, RD is observed on the laptop’s CC line, indicating a sink. The charger presents Rp on its CC line, but the laptop never sees a proper PD handshake. VBUS remains at ~0–0.5 V or a brief, unstable ramp that collapses.
• Investigate cables: Replace the cable with a known-good PD-rated cable. If the negotiation now completes and VBUS ramps to 20 V, the issue was cable quality or wiring.
• Check the charger’s PD controller: If the handshake still fails, examine the firmware or configuration of the charger’s PD controller; a misconfiguration can cause the Source to fail to provide the desired contracts.
• Check the laptop side: If the laptop’s PD controller rejects a contract due to a current limit or a profile mismatch, the handshake will fail even with a healthy charger. Adjustments in the Sink’s Request or the Source’s capabilities might be needed.

Takeaway: PD signaling is a coordinated dance between the source and sink. If one partner drops out or misinterprets the other’s messages, you’ll observe the kind of partial or failed negotiation described above. With careful waveform inspection and, if possible, protocol decoding, you can pinpoint whether the problem lies in the cable, the PD controller firmware, or the physical layer.

Conclusion: turning PD waveforms into actionable fixes

USB-C Power Delivery offers a powerful mechanism to deliver the right amount of power where it’s needed, but diagnosing problems requires attention to both the signals and the power path. An oscilloscope-based approach centers on three pillars:

• Observe the PD signaling on CC lines (and, when appropriate, use a protocol analyzer to interpret PD messages).
• Watch the VBUS path for correct ramp timing and stable operation once a contract is in place.
• Ensure the physical layer—the cable, connectors, and protection networks—aren’t introducing faults that mask the real PD state.

With the steps and tips outlined in this guide, you can systematically isolate issues, verify correct operation, and build a reliable PD solution. Practice with known-good devices, document your traces, and gradually introduce complexity (different cables, different devices, and different PD controllers). Over time, you’ll develop a keen eye for the telltale PD waveform cues and a robust workflow for turning oscilloscope traces into concrete fixes.

Additional resources and reading

To deepen your understanding, consider exploring these resources:

• USB-IF USB Type-C Cable and Connector specifications for CC line behavior, Rp/Rd values, and orientation detection.
• USB Power Delivery specification updates for PD message formatting and state machines (Source Capabilities, Request, Accept, etc.).
• PD protocol analyzer tools and open-source decoders that can translate CC line activity into readable PD messages.
• Application notes from PD controller vendors that describe typical test setups and recommended measurement practices.

Armed with the knowledge in this guide and a methodical approach, you’ll be well-equipped to troubleshoot USB-C PD signals like a pro, using nothing more than an oscilloscope, careful probing, and a systematic workflow.