The Power Delivery 2.0 Protocol in Action

Figure 1: A high-level view of a PD 2.0 power
contract negotiation

The Power Delivery 2.0 protocol brings a boatload of intelligence to the process of establishing power relationships between partners in a USB Type-C link. In previous posts, we've examined the basics of the two standards, the workings of USB Type-C cable detection, how dual-role port devices are handled, and PD 2.0 messaging. Next, let's look at PD 2.0 in action by deconstructing the initialization of a Google Chromebook laptop, which was one of the first Power Delivery devices on the market.

At a high level, Figure 1 shows what a power contract negotiation looks like: The source sends a list of its capabilities, each one being considered a separate Power Data Object (PDO). In this case, the source has two PDOs, one fixed and one variable (the latter enables developers to opt for less expensive power supplies with looser regulation). In its fixed PDO, this source offers a limited 2A @ 5V. The sink then requests one of the two PDOs. If it were to request the variable PDO, it must specify both operating and maximum current draws. In our example, the sink requests the fixed PDO (note that it does not request more current capability than is advertised). The source responds by accepting the request.

Figure 2: The entire Power Delivery initialization sequence
of a Google Chromebook laptop

Figure 2 gives a 30,000-foot view of the Google Chromebook's Power Delivery initialization. The image represents the entire power-on sequence after the laptop is connected to the USB Type-C power supply that accompanies it in the box. The Teledyne LeCroy Voyager M310C USB 3.1 and Power Delivery analyzer/exerciser being used for the analysis. The Voyager M310C has native Type C connectors that place it in line for capturing the exchanges.

The first step in initialization is detection of the PD source by the Configuration Channel (CC) line. The analyzer captures state changes on the CC line and labels them "CC Event." Were we to unstack the CC Events, we'd see the left port flipping between Rp and Rd terminations every 75 ms. This is the expected behavior of a dual-role port device (all laptops are DRPs) because they need to source current for charging and supply Vbus for bus-powered devices.

With the power brick connected and showing Rp (source), the Chromebook itself flips to showing Rd, making it the default current sink. The analyzer also can detect the pull-up voltages on the CC line from the source. It knows the default current is 3A and specifies it as such in the capture.

If we were using an E-marked cable, we would see cable messages at this point. But because the power brick uses an unmarked cable, it moves directly into negotiation of an explicit power contract. If we expanded all of the transactions under the umbrella of Power Negotiation, it starts with the source advertising its capabilities. The source advertises a Power Data Object (PDO) count of three, meaning that the laptop has three different PDOs to choose from. The laptop then makes a request of the source, the source must accept the request, and then send a "power supply ready" message. The source may also send a reject or wait message if it's not prepared to support the request.

Following successful power negotiation, the source sends a "get sink capabilities" request to the side of the link that came up as the sink. This lets the power supply know what power levels the laptop can operate from. A closer look at this group of messages reveals that it is not unlike the source's advertising of its capabilities. There are three 32-bit PDOs coming from the Chromebook: a fixed and battery PDO as well as a variable PDO. The source uses this information to set policies at the higher layers.

Next, the sink requests a data-role swap, initiating it by sending a control message. The source needs to respond with a good-CRC message and send an explicit accept message. Why does the Chromebook request the swap? By rule, the source should come up as a host by default. But power bricks are not like a device with real USB host functionality. In a quirk of the PD specification, the laptop comes up as a device every time it's connected to its own power supply. It cannot even send a command from the power input until it switches into the host role, after which it must interrogate the power supply to learn whether it even supports USB.

Once the Chromebook is in charge as the host, it can query the power brick to learn whether it supports any alternate modes or even USB itself (most power bricks do not). This is where vendor-defined PD messages come into play. The Chromebook uses the "discover identity" query to identify its port partner and "discover SVID" to dig up any additional vendor-ID information. The Google-supplied power brick reports a Google SVID, and if the Chromebook trusts that SVID, it then looks for any alternate modes that the power brick might support (it has only one mode of operation).

After determining what modes of operation the power brick offers, the laptop chooses the appropriate (and again, often only) mode. After sending a few proprietary messages, the Chromebook issues a new request to re-negotiate the power contract. Now that it knows what the power brick can deliver, it requests a supply of 3A @ 20V. The CC line goes quiet and the initialization is now complete.

Thanks for hanging in for our in-depth look at USB Type-C and the Power Delivery protocol!