
Over the last several months, I have been working on Dr. PD, an open-source USB Power Delivery analyzer and programmable sink. Diving deep into the world of USB-PD and USB-C has given me a unique appreciation for these rich technologies, and I want to share some of the things I have learned.
As we saw in the previous part, it has taken 35 messages for the Mac and the iPad to set up a basic power contract and establish USB serial communications. There still remains an important task: negotiating a long-term power arrangement.
Recall that both devices are Dual-Role Ports, meaning that they can act as either source or sink based on demand. In practice, the Mac will usually act as the source — though not always, since there are ways to charge the Mac from an iPad, which is quite cool — but that does not diminish the need for a more thorough inspection of the iPad’s power requirements.
After all, there might be multiple devices connected to the Mac’s four USB-C ports, and the Mac itself has a limited amount of power available to charge other devices, even when it is connected to mains power. Therefore, its power-management system needs to understand the needs of each connected device so it can better balance the amount of power sent to each port.
Phase 5: I've got the power
The power negotiation begins with the Mac asking the iPad about its identity and battery setup:
|
Get Battery Cap |
Source |
Sink |
Battery capability request:
|
|
Battery Capabilities |
Sink |
Source |
Battery capabilities:
|
|
Get Battery Status |
Source |
Sink |
Battery status request:
|
|
Battery Status |
Sink |
Source |
Battery status:
|
|
Get Status |
Source |
Sink |
|
|
Status |
Sink |
Source |
Port status:
|
|
Get Manufacturer Info |
Source |
Sink |
Manufacturer information request:
|
|
Manufacturer Info |
Sink |
Source |
Manufacturer information:
|
In this exchange, the Mac first asks the iPad for information about its battery. Recall from Part 1 that the Mac learned the iPad has one battery from the Sink_Capabilities_Extended message. The iPad replies that it has a 40 Wh capacity, and that the last full charge also brought the battery to 40 Wh. This, incidentally, is a lie: this iPad’s battery is on its last legs and barely reaches 80% capacity.
Next, the Mac asks for the status of the iPad’s battery. The iPad replies that it is full and that it is charging. That is true on both counts, since the battery was at maximum charge and the iPad was topping it up with power from the Mac.
The Mac then asks for the iPad’s status so that it can determine whether there are any conditions, such as an overtemperature warning, that could affect the power profile. The iPad’s response is entirely unremarkable—to the point that it is probably perfunctory rather than a reflection of its actual status.
Finally, the Mac asks for the iPad's manufacturer information, and the iPad replies with its name, VID, and PID.
Phase 6: My turn
We're finally getting into the home stretch now.
|
Get Source Cap Extended |
Sink |
Source |
|
|
Source Capabilities Extended |
Source |
Sink |
Source capabilities extended information:
Could not decode all source capability data: Legacy 24-byte Source Capabilities Extended Data Block: missing EPR Source PDP Rating byte required by USB PD 3.2. |
|
Get Sink Cap Extended |
Sink |
Source |
|
|
Sink Capabilities Extended |
Source |
Sink |
Sink capabilities extended information:
Could not decode all sink capability data: Legacy 21-byte Sink Capabilities Extended Data Block: missing EPR Sink PDP bytes required by USB PD 3.2. |
|
Get Battery Cap |
Sink |
Source |
Battery capability request:
|
|
Battery Capabilities |
Source |
Sink |
Battery capabilities:
|
|
Get Battery Status |
Sink |
Source |
Battery status request:
|
|
Battery Status |
Source |
Sink |
Battery status:
|
|
Get Status |
Sink |
Source |
|
|
Status |
Source |
Sink |
Port status:
|
|
Get Manufacturer Info |
Sink |
Source |
Manufacturer information request:
|
|
Manufacturer Info |
Source |
Sink |
Manufacturer information:
|
|
Vendor Defined |
Sink |
Source |
Structured Vendor Defined Message: DISCOVER_IDENTITY REQ
|
|
Vendor Defined |
Source |
Sink |
Structured Vendor Defined Message: DISCOVER_IDENTITY ACK
Discover Identity data:
|
These are essentially the same messages that the Mac sent to the iPad, only in reverse. Note how the iPad asks the Mac for both its source and sink capabilities. This is necessary to determine whether it should request a role swap, which, if accepted by the Mac, would cause the source and sink roles to reverse.
In this case, no role swap takes place, because there is no reason for one. Instead, the two devices finally decide that it is time to speak in their own dialect.
Phase 7: Secret lovers
With power negotiations out of the way, the Mac and the iPad take full advantage of the Vendor_Defined message’s ability to carry arbitrary information, exchanging a flurry of opaque data:
|
Vendor Defined |
Source |
Sink |
Unstructured Vendor Defined Message
Vendor payload Vendor Data Objects:
|
|
Vendor Defined |
Sink |
Source |
Unstructured Vendor Defined Message
Vendor payload Vendor Data Objects:
|
|
Vendor Defined |
Source |
Sink |
Unstructured Vendor Defined Message
Vendor payload Vendor Data Objects:
|
|
Vendor Defined |
Sink |
Source |
Unstructured Vendor Defined Message
Vendor payload Vendor Data Objects:
|
And so on, another forty times or so. Unfortunately, there is no way to tell what the two devices are saying to each other, but it certainly looks like an interesting conversation—or, at least, a pretty detailed one.
This kind of deep exploration is just one of the many activities that a USB-PD protocol analyzer like Dr. PD enables! It also lets you troubleshoot faulty connections, characterize power supplies, and much more! If you want your own, you can join our prelaunch page on Crowd Supply for product updates, or stay tuned here for more posts on USB-C, Power Delivery, and the hardware design behind Dr. PD.
Marco Tabini
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.