In a previous blog, we talked about a basic Type-C implementation without USB-PD. Today, we will discuss all the wonderful capabilities USB-PD brings to the Type-C connector plus a very important topic: SAFETY.
A non-PD Type-C implementation allows plug flipping and cable swapping. It also allows significant capability over BC 1.2, with non-PD Type-C Vbus up to 5V and 3A.
Adding USB-PD to your Type-C implementation allows optional Vbus up to 20V and 5A, plus power direction swap. What this means is your Type-C USB-PD laptop could potentially bus-power a Type-C USB-PD portable projector. Or conversely, a projector could charge your laptop.
USB-PD also enables Alternate Mode. This means that specifically designated pins in the Type-C connector can be reconfigured to output Alternate Mode signals like Thunderbolt, DisplayPort, and HDMI instead of USB.
All that magic happens with the CC (Configuration Channel) signal. A 300Kbps, half-duplex, BiPhase Mark Coded, multi-drop 4b5b Protocol with error detection/recovery that enables communication between the Host, Device, and Cable.
Once a valid Type-C attachment is detected, the Source advertises its capabilities (Power Profiles, Alternate Modes) over the CC line. The Device similarly advertises and reviews the choices available, and communicates what capabilities it will accept for the negotiated Power Delivery contract. Figure 1 shows the decoded CC line communication plus Vbus as it goes from Detach to Default to the explicit contract of 20V.
Figure 1. N8837A display of CC decode and Vbus
In the previous example, the power contract was correctly negotiated and the transition happened seamlessly. But does this happen correctly every time? Experiments can be setup to repeat PD contracts, initiate Power Role Swaps, and force Hard Resets. And all the while monitoring the CC protocol and Vbus for illegal and non-compliant states. Figure 2 illustrates how the S-series oscilloscope can be setup to real-time trigger on any USB-PD protocol state and error states.
Figure 2 Real-time trigger on specific protocol states and errors
In a previous blog, I talked about designing and testing high-speed 10G silicon for over-compliance. That very same concept applies here. We should not design nor should we test for just compliant conditions. We must always design and test for non-ideal, stressed, and illegal conditions. So your Battery charges great when connected to 5V and 1.5A. But what happens if someone connects your USB-PD compliant Battery to a non-compliant Source that outputs 20V and 5A? Your Source could implement USB-PD correctly and advertise 9V and 3A. But what happens if a non-compliant Sink advertises 9V/3A but actually draws 5A? Plus, even compliant products sometimes fail or may intermittently be non-compliant.
Some of you will be designing legacy non Type-C, non USB-PD products that connect with certified adapters to USB-PD products. Default USB 2.0 Power is 5V and 500mA. If the USB-PD contract is properly negotiated by the specified Rp/Rd legacy termination resistor, both Source and Sink operate as advertised and it’s all great. But remember that your legacy USB 2.0 product could be connected to a non-compliant Type-C USB-PD implementation and see 20V/5A or more.
In particular, the USB 3.1, Type-C, and USB-PD specifications do not address how to design products that are exposed to non-compliant and illegal operating conditions. We must account for this possibility in our designs and in our testing.
While testing your Sink, one method is to use a Programmable Supply to generate non-compliant Source voltages with over-voltage, over-current, noise, ripple, and other transient conditions. Figure 3 shows illegal Vbus transitions being applied while testing a Sink.
Figure 3. N6705B Source with non-compliant power profile
In Figure 4, you see a USB-PD Source capable of 60W subjected to an over-current Sink. In this particular example, the over-current protection circuitry of this USB-PD Source immediately shuts down its output for safety.
Figure 4. N6705B E-Load creating over-current conditions
I hope this blog was helpful in illustrating all the great features that USB-PD can bring to a basic Type-C implementation. But more importantly, that the flexibility and enhanced Power Profiles of USB-PD can potentially lead to serious safety issues. Your designs must clearly be compliant to the specifications but you must also design and test for connecting to products that are non-compliant, or even intermittently non-compliant.