USB Power Delivery (PD) is one of the new exciting features of the latest USB-c connector and standard. The USB host side is adding a power supply called source and the USB device side is adding a sink. PD Communication is happening over one of the 2 CC pins on the USB-C connector. For simple backwards compatibility a 5.1 KOhm resistor to ground is added to each CC pin. This enables 5 V and up to 3 A equaling 15W of power on the interface.
For other power settings, the source and sink communicate over the CC interface to establish a power contract that enabled up to 100 W ( 5 A @ 20V) for standard power options and up to 240 W (up to 5 A @ 48V) for extended power range supplies. Only one CC pin is used for bidirectional communication and other other pin is unused or used as power supply for a potentially present e-marker chip in the cable.
My goal is now to decode the messages that are send over the CC interface.
My devices available for the test setup are:
- A 90W USB-C PD supply with fixed voltage settings (5 V, 9 V, 12 V, 15 V, 20 V with up to 4.5 A)
- A 60W USB-C PD Programmable Power Supply ( PPS ) with up to 21 V (in PPS mode) and 3 A.
- A PD Sink of my own design using the Cypress/Infineon CYPD3177 PD Sink controller
- A PD Sink Buddy board, as a working PPS sink.
- A PD CYPD3176 eval board, which I have not integrated with yet.
My decoder of choice is the free Sigrok/Pulseview software with a USB PD decoder module. As hardware interface I am using a generic 24 MHz 8 channel logic analyzer based on the FX2 chip.
The 1st issue I ran into was the voltage level of the CC signals is ~1.2 V as the logic high level which did not trigger the logic analyzer consistently. This is not a surprise, which logic high threshold of 3.3V CMOS or TTL being 2 V. So I am going to built one (it turned out to be 3 different one's until I got it fully working) level shifter to listen in on the communication on the CC.
Short detour in signal conditioning.
The first level shifter I build is a very simple one, normally used for open drain signals. It was the first choice because it only needs 3 components, which I all had on hand. I reduced the pull-up to 510 Ohm for sharper edges without success.
This setup works halfway. The logic analyzer is able to decode the message packets, but the original signal gets distorted bad enough, that the sink/source do not recognize and answer to the initial messages. The initial CC message here is a source capabilities broadcast of the PD source to tell the sink available voltage and current values. Here is a visualization of the captured signal and its decoded content,
With this approach not working, I decided to try an opamp level shifter to increase the input impedance to not distort the actual communication signal. The opamp circuit is a straight forward non-inverting configuration with a gain of 2 to boost the 1.2V signal to >2V for the minimum high level threshold.
--
Side tangent on opamp selection:
My first choice (again a component on hand) was the Microchip MIC6271. It is rail to rail and has a 2 MHz gain bandwidth and a slew rate of 0.9V/usec. PD messages are sent at 300 KHz(???) +-10% with rise and fall time of measured 1 usec. Using the rise time for calculation, this signal is already at the limit of the opamp capabilities. 1 usec corresponds to 1MHz and a gain of 2 calculates to 2 MHz gain-bandwidth already, leaving no headroom to the max GBW of the opamp. Also the slew rate of the signal is ~1.65V/usec measured, exceeding the opamp spec. This adds up to a amplified signal not representing the input signal at all. See image below, blue channel 2 is the CC signal; yellow channel 1 is the amplified signal.
So, a different opamp with >5 MHz GBW and >2 V/usec slew rate is on order. Unfortunately, I have nothing in the parts bin, so this route needs to wait to be explored further. If this paragraph sounds familiar, you are right. I used it as an example at baldengineer 's post about opamp characteristics and why it is important to pick the correct ones.
--
Next try is a straight LM393 comparator. This will loose the nice controlled slope of the signal edges, but if it keeps the signal intact and lets the LA sample the signal it is a win/win.
And this approach is the winning one. The opamp's open collector output got pulled up with a strong pull up of 510 Ohm to give a nice crisp rising edge. The reference voltage is set to 100/(100+14.3) = 0.42V. As you can see on the scope plot, the level-shifted signal is not complete synchronous any more. The low pulses are somewhat wider than the high pulse, but the tolerance is still OK for the Pulseview decoder to work properly.
I know those are a lot of details, that don't really contribute to the final outcome and there was a discussion raging about knowing your audience. But all those details are leading to the final solution and I am documenting this for myself as well. So technically I am my own audience and I know exactly what I want.
Pulseview is configured really simple. Once the logic analyzer is connected, it is only a matter of selecting the USB PD decoder through the [protocol select] dialogue and have the level shifter output connected to the right LA input. I selected a 4 MHz sampling rate and 20 MSample buffer for 5 seconds of record time. I got decoded packets literally on the first try. If it does not work, just flip the USB connector, communication might be on the other CC pin.
So here is a run-down of screen shots of the PD contract negotiation and the single communication packets. I have set the sink to request a 9 V, 1 A contract. Every good packet gets acknowledged with a Good CRC response from the receiver. There is always a preamble sent to synchronize the receiver to the serial data stream. Encoding is done using a32-bit 4b/5b encoded biphase mark code (BMC).
Full sequence:
Sink: Capabilities request to the source
Source: Good CRC
Source: Source Capabilities report
Sink: Good CRC
Sink: 9 V 1 A PD Fixed Contract Request
Source: Good CRC
Source: Contract Accept
Sink: Good CRC
I think that is pretty cool. I will have to add a scope capture of the CC and the VBUS connections to see the power turned on by the source and the output power switched on at the sink end to get an idea of the timing of those events.
Next I have to look at a PPS (programmable power supply) contract negotiation with the Power Integrations supply from the roadtest.
Useful resources:
shabaz 's USB PD recent blog posts:
