USB Type-C and power delivery 101 – Power delivery protocol

As described in the first part of this two-part series, USB Type-C is the newly introduced and powerful interconnect standard for USB. When paired with the new Power Delivery (PD) specification, Type-C offers enhancements to the existing USB 3.1 interconnect that lower the cost and simplify the implementation of power delivery over USB.  In this article, we describe the USB Type-C power delivery protocol.

Figure 9 shows the PD message format. All PD messages are transmitted at 300KHz +/- 10% over the CC line.  The first 64 bits (Preamble ) are an alternating 1, 0 pattern so that the receiver can synchronize with the actual transmitted clock. The next 16-bit word (Address or Type ), contains the message address, indicating the message recipient or other type information (SOP* communication explained below). The next 16-bit field contains the message header, which is encoded as shown in Figure 9. The header field includes a data object count (#Data Objects).  If the data object count is 0, then the message type is “control.” If it is 1 through 7, then up to seven 32-bit data objects follow, and the message type is “data.” A 32-bit CRC is transmitted, followed by a 4-bit end of packet (EOP) token that completes the message. If the calculated CRC is the same as the received CRC, then the Type-C device physical layer passes the decoded message up to its protocol layer for decoding. Refer to the USB-PD specification for more details on the message structure.


Figure 9. PD message format (Source: Cypress Semiconductor)

The USB-PD specification defines two types of Messages (see Table 4):

  • Control Messages are short and manage the Message flow between Port Partners or for exchanging Messages that require no additional data.

  • Data Messages exchange information between a pair of Port Partners. Data messages include exposing capabilities and negotiating power, Built-In-Self-Test (BIST), and custom messaging defined by the OEM.

Table 4. PD Message Types: Control and Data (Source: Cypress Semiconductor)

Control Message

Description

GoodCRC

Message sent by the receiver to acknowledge that the previous Message was correctly received

GotoMin

It is a directive to the Sink Port to reduce its operating power level to the amount specified in the Minimum Operating Current field of its latest Sink Request Data Object

Accept

Sent by the recipient of certain messages like Request (during a power negotiation), DR_SWAP, PR_SWAP, VCONN _SWAP, etc. to signal that it is willing to do a power contract or role swaps

Reject

Sent by the recipient of certain messages like Request (sent by Sink during a power negotiation) to signal that it is unable to meet the power profiles requested by the Sink in Request message or as a reply to the messages like DR_SWAP, PR_SWAP, VCONN _SWAP, etc. to signal that it is unable to do role swaps

PS_RDY

[Power Supply Ready] Message sent by the Source (or by both the new Sink and new Source during the Power Role Swap sequence) to indicate its power supply has reached the desired operating condition

Get_Source_Cap

[Get Source Capability] Message sent by a Port to request the Source Capabilities and Dual-Role capability of its Port Partner (e.g. Dual-Role capable). The Port shall respond by returning a SourceCapabilities Message. A Sink Port, without Dual-Role capability, shall return a Reject Message

Get_Sink_Cap

[Get Sink Capability] Message sent by a Port to request the Sink Capabilities and Dual-Role capability of its Port Partner (e.g. Dual-Role capable). The Port shall respond by returning a Sink_Capabilities Message. A Source Port, without Dual-Role capability, shall return a Reject Message

DR_Swap

[Data Role Swap] Message used to swap the port’s data role (DFP / UFP) between the Port Partners both utilizing Type-C connectors while maintaining the direction of power flow over VBUS

PR_Swap

[Power Role Swap] Message used to swap the port power role (power provider / power consumer) between the Port Partners both utilizing Type-C connectors while maintaining the data role of the ports

Vconn_Swap

Message sent by either Port Partner to request an exchange of VCONN Source

Wait

Sent by the recipient of certain messages like Request (during a power negotiation), DR_SWAP, PR_SWAP, VCONN _SWAP, etc to signal that it is unable to meet the power profiles requested by the Sink in the Request message or unable to do role swaps at this point of time

SoftReset

Message initiated by either the Source or Sink to its Port Partner requesting a Soft Reset. It is used to recover from PD Protocol Layer errors.

Data Message

Description

SourceCapabilities

A Source Port shall report its capabilities in a series of 32-bit Power Data Objects as part of a SourceCapabilities Message. Power Data Objects (PDOs) are used to convey a Source Port’s capabilities to provide power

Request

Message sent by a Sink to request power, typically during the request phase of a power negotiation. The Request Data Object shall be returned by the Sink making a request for power

SinkCapabilites

A Sink Port shall report power level capabilities in a series of 32-bit Power Data Objects. These are returned as part of a SinkCapabilities Message in response to a Get_Sink_Cap Message. This is similar to that used for Source Port capabilities with equivalent Power Data Objects for Fixed, Variable and Battery Supplies as defined in this section. Power Data Objects are used to convey the Sink Port’s operational power requirements

BIST

[Built In Self-Test] Message sent to request the Port to enter Physical Layer test mode

VendorDefined

[Vendor Define Message – VDM] Message provided to allow vendors to exchange information outside of that defined by the USB-PD specification


Figure 10. Successful Power Negotiation. Note: Rqt – Request; Ack – Acknowledge; VDM – Vendor Defined message (Source: Cypress Semiconductor)

Figure 10 shows the message flow during a successful power negotiation between any two generic PD-enabled Type-C devices connected by an Electronically Marked Type-C cable (see Figure 11).  Note that each command and data message is acknowledged by the receiver of the message, which sends a GoodCRC response back to the initiator (not shown in Figure 10).


Figure 11. Type-C connection with EMCA (Source: Cypress Semiconductor)

  • The DRP, which got locked as a DFP (Source), first discovers the presence of an EMCA attached due to the presence of Ra. It queries for the characteristics of the cable by sending the DiscoverIdentity

  • The cable responds with the cable characteristics using the DiscoverIdentity ACK response message (see Figure 10).

  • The DFP (Source) also detects the presence of a UFP (Sink) due to the Rd The DFP (Source) then sends the source capabilities message to the UFP (Sink) that represents the DFP (Source) power supply’s present capabilities as in Figure 10. In Figure 10, this message sends out the power supply capability as the ability to source 5 V at 3 A and 9 V at 3 A.

  • The UFP (Sink) then uses a Request message for, in this case, 3 A of current at 9 V.

  • The DFP (Source) sends an Accept message and then sends a PS_RDY message as an indication that the source is ready to start sourcing the new power level on VBUS .

The UFP (Sink), on detecting VBUS , could start enumeration if it had USB data channels.

SOP* Communication in USB PD

Power Delivery communication starts with sequences of special symbols called K-code markers to delineate the start of a packet. K-codes are provided by the 4b5b line-encoding scheme used in PD communication to delineate packet boundaries.

In addition to encoding data, K-codes are used for special control functions, such as a hard reset or cable reset. The special K-code sequence signifying the start of sequence is called the Start Of Packet (SOP). Three sequences are defined: SOP, SOP’, and SOP’’. SOP* is used to refer all the three SOP sequences. Figure 12 defines and differentiates SOP* packets:

  • SOP Packet : Any Power Delivery packet that starts with an SOP sequence. The communication between Port Partners (DFP and UFP) uses SOP packets. These packets are not recognized by either Cable Plug.

  • SOP’ Packet: Any Power Delivery packet that starts with an SOP’ sequence used to communicate with a Cable Plug. SOP’ packets are recognized by the electronics in the Cable Plug attached to the DFP (cable plug marked SOP’ in Figure 12) and are not recognized by the other Cable Plug or the port partner in UFP.

  • SOP’’ Packet: Any Power Delivery packet that starts with an SOP’’ sequence used to communicate with a Cable Plug when SOP’ packets are being used to communicate with the cable plug at the other end. SOP’’ packets are recognized only by the electronics in the Cable Plug attached to the UFP (cable plug marked SOP” in Figure 12) and are not recognized by the other Cable Plug attached to the DFP or the port partner in UFP.

Response to SOP” packets by the cable plug attached to UFP is optional, but the response to SOP’ packets by the cable plug attached to DFP is mandatory in an EMCA.  Note that the term “Cable Plug” in the SOP’/SOP’’ communication case is used to represent a logical entity in the cable that is capable of PD communication. These entities may or may not be physically located in the plug.


Figure 12. SOP* Communication (Source: Cypress Semiconductor)

SOP* communication takes place over a single wire (CC). This means that SOP* communication periods must be coordinated to prevent important communications from being blocked. Communications between the Port Partners (SOP packets) take precedence, implying that communications with the Cable Plug (SOP’/ SOP” packets) can be interrupted. See the USB PD specification for more details.

Role Swapping in USB-PD

Before the USB-PD specification came into being, the USB host (such as a laptop, for example) was always the power provider and the USB device (i.e., a mouse) was always the power consumer.  Charging the battery of the host computer was considered a separate action. The PD specification greatly improves the USB ecosystem and defines power roles (VBUS Source and Sink) that are independent of the data roles (USB host and USB device). This includes the ability to swap power and data roles independently. An example of such versatile behavior is a wall mounted peripheral device such as a monitor can charge the battery of a USB host such as a notebook or PC.

The PD specification defines three types of role swaps:

  • Data Role Swap (DR_SWAP): Exchange the DFP (Host) and UFP (Device) roles between Port Partners over the USB Type-C connector. This does not swap the Rp and Rd terminations on the CC line of the port partners as the port power role remains intact.

  • Power Role Swap (PR_SWAP): Exchange the Source and Sink roles between Port Partners. This also swaps the Rp and Rd terminations on the CC line of the port partners.

  • VCONN Swap (VCONN_SWAP): Exchange the VCONN (cable plug power) Source between Port Partners.

Table 5 summarizes the behaviors of a port in response to the three USB PD swap commands.

Table 5. USB PD Swapping Port Behavior Summary (Source: Cypress Semiconductor)

DFP/ UFP Data Roles

Rp / Rd

VBUS Source/ Sink

VCONN Source

PR_SWAP

Unchanged

Swapped

Swapped

Unchanged

DR_SWAP

Swapped

Unchanged

Unchanged

Unchanged

VCONN _SWAP

Unchanged

Unchanged

Unchanged

Swapped

Figure 13 shows the message sequence during a DFP-initiated successful DR_SWAP. It can be initiated by either the DFP or the UFP. One example scenario that will need DR_SWAP for proper operation is when a USB Type-C Monitor (DRP) locks as a DFP/ Source initially when connected to a USB Type-C host (DRP).  Thus the monitor is sourcing power to the Type-C host. For proper functionality, the Type-C monitor should be UFP with the Type-C host as DFP. DR_SWAP enables the swap to be initiated by the monitor.


Figure 13. DFP initiated DR_SWAP (Source: Cypress Semiconductor)

Figure 14 shows the message sequence during a Source initiated successful PR_SWAP. It can be initiated by either the source or the sink. One example scenario that will need PR_SWAP for proper operation is when a USB Type-C Monitor (DRP) locks as a UFP/ Sink initially when connected to a USB Type-C laptop (USB host/ DRP).  In this case, the monitor initially sinks power from the Type-C host. PR_SWAP is needed to enable the monitor to charge the Type-C laptop.  This swap can be initiated either by the Type-C monitor or the laptop.


Figure 14. Source initiated PR_SWAP (Source: Cypress Semiconductor)

Figure 15 shows the message sequence during a DFP initiated successful VCONN _SWAP. It can be initiated by either the current VCONN source or VCONN sink. As shown in the figure, both sources will be on at the same time for a short while following the Accept message. This is because the new VCONN source turns on following the Accept message and before the PS_RDY instance, and the old VCONN source turns off after the PS_RDY instance. This sequence of VCONN powering is, as per the USB-PD specification, to ensure that the cable controller always remains powered. Furthermore, to avoid the two VCONN sources being on at the same time, the specification mandates an isolation element between the two VCONN sources (e.g. a diode) to select a particular source among the two when both are available.


Figure 15. DFP initiated VCONN _SWAP (Source: Cypress Semiconductor)

This article has provided a high level view of the basics of the USB Type-C and Power Delivery (PD) specifications. For additional information, see Type-C Essentials, Type-C Resources, and the USB Type-C and Power Delivery FAQ.

References

Gayathri Vasudevan is a Staff applications engineer at Cypress Semiconductor, Bangalore. Gayathri is responsible for supporting customers on all wired USB products, developing specifications for next generation products, and creating solution demos, application notes and other collateral for new products. She has a degree in electronics and communication engineering.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.