USB Power Delivery study

1、sop*（start of packet） Communication

1.1 Introduction

The Start of Packet (or SOP) is used as an addressing scheme to identify whether the Communications were intended

for one of the Port Partners (SOP Communication) or one of the Cable Plugs (SOP’/SOP’’ Communication). SOP/SOP’

and SOP’’ are collectively referred to as SOP*. The term Cable Plug in the SOP’/SOP’’ Communication case is used to

represent a logical entity in the cable which is capable of PD Communication and which might or might not be

physically located in the plug.

The following sections describe how this addressing scheme operates for Port to Port and Port to Cable Plug

Communication.

1.2 SOP Communication

SOP Communication is used for Port-to-Port communication between the Source and the Sink. SOP Communication is

recognized by both Port Partners but not by any intervening Cable Plugs. SOP Communication takes priority over

other SOP* Communications since it is critical to complete power related operations as soon as possible. Message

sequences relating to power are also allowed to interrupt other sequences to ensure that negotiation and control of

power is given priority on the bus.

1.3 SOP’/SOP’’ Communication with Cable Plugs

SOP’ Communication is recognized by electronics in one Cable Plug (see [USB Type-C 2.0]). SOP’’ Communication can

also be supported when SOP’ Communication is also supported. SOP’ and SOP’’ assignment is fixed and does not

dynamically change.

SOP Communication between the Port Partners is not recognized by the Cable Plug. Figure 2-2 outlines the usage of

SOP* Communications between a VCONN Source (DFP/UFP) and the Cable Plugs.

All SOP* Communications take place over a single wire (CC). This means that the SOP* Communication periods must

be coordinated to prevent important communication from being blocked. For a product which does not recognize

SOP/SOP’ or SOP’’ Packets, this will look like a non-idle channel, leading to missed packets and retries.

Communications between the Port Partners take precedence meaning that communications with the Cable Plug can

be interrupted but will not lead to a Soft or Hard Reset.

When no Contract or an Implicit Contract is in place (e.g., after a Power Role Swap or Fast Role Swap) only the Source

port that is supplying VCONN is allowed to send packets to a Cable Plug (SOP’) and is allowed to respond to packets

from the Cable Plug (SOP’) with a GoodCRC in order to discover the Cable Plug’s characteristics (see Figure 2-2).

During this phase all communication with the Cable Plug is initiated and controlled by the Source which acts to

prevent conflicts between SOP and SOP’ Packets. The Sink does not communicate with the Cable Plug and Discards

any SOP’ Packets received.

When an Explicit Contract is in place the VcONN Source (either the DFP or the UFP) can communicate with the Cable

Plug(s) using SOP’/SOP’’ Packets (see Figure 2-2). During this phase all communication with the Cable Plug is

initiated and controlled by the VCONN Source which acts to prevent conflicts between SOP* Packets. The Port that is

not the VCONN Source does not communicate with the Cable Plug and does not recognize any SOP’/SOP’’ Packets

received. Only the DFP, when acting as a VCONN Source, is allowed to send SOP* in order to control the entry and

exiting of Modes and to manage Modal Operation.

2、Physical Layer

2.1 Physical Layer Functions

The USB PD Physical Layer consists of a pair of transmitters and receivers that communicate across a single signal wire (CC). All communication is half duplex. The PHY Layer practices collision avoidance to minimize communication errors on the channel.

The transmitter performs the following functions:

• Receive packet data from the protocol layer.

• Calculate and append a CRC.

• Encode the packet data including the CRC (i.e., the payload).

• Transmit the Packet (Preamble, SOP*, payload, CRC and EOP) across the channel using Biphase Mark Coding (BMC) over CC.

The receiver performs the following functions:

• Recover the clock and lock onto the Packet from the Preamble.

• Detect the SOP*.

• Decode the received data including the CRC.

• Detect the EOP and validate the CRC:

o If the CRC is Valid, deliver the packet data to the protocol layer.

o If the CRC is Invalid, flush the received data.

2.2 Symbol Encoding

Except for the Preamble, all communications on the line Shall be encoded with a line code to ensure a reasonable level

of DC-balance and a suitable number of transitions. This encoding makes receiver design less complicated and allows

for more variations in the receiver design.

4b5b line code Shall be used. This encodes 4-bit data to 5-bit symbols for transmission and decodes 5-bit symbols to

4-bit data for consumption by the receiver.

The 4b5b code provides data encoding along with special symbols. Special symbols are used to signal Hard Reset,

and delineate packet boundaries.

2.3 Packet Format

The packet format Shall consist of a Preamble, an SOP*, packet data including the Message Header, a CRC and an EOP. The packet format is shown in Figure 5-3 and indicates which parts of the packet Shall be 4b/5b encoded. Once 4b/5b encoded, the entire Packet Shall be transmitted using BMC over CC. Note that all the bits in the Packet, including the Preamble, are BMC encoded.

2.3.1 Start of Packet Sequences

2.3.1.1 Start of Packet Sequence (SOP)

SOP is an ordered set. The SOP ordered set is defined as: three Sync-1 K-codes followed by one Sync-2 K-code (see Table 5-5).

A Power Delivery Capable Source or Sink Shall be able to detect and communicate with packets using SOP. If a Valid SOP is not detected (see Table 5-3) then the whole transmission Shall be Discarded.

2.3.1.2 Start of Packet Sequence Prime (SOP’)

The SOP’ ordered set is defined as: two Sync-1 K-codes followed by two Sync-3 K-codes (see Table 5-6).

2.3.1.3 Start of Packet Sequence Double Prime (SOP’’)

The SOP’’ ordered set is defined as the following sequence of K-codes: Sync-1, Sync-3, Sync-1, Sync-3 (see Table 5-7)

2.3.2 End of Packet (EOP)

The end of packet marker Shall be a single EOP K-code as defined in Table 5-1. This Shall mark the end of the CRC.

After the EOP, the CRC-residual Shall be checked. If the CRC is not good, the whole transmission Shall be Discarded,

if it is good, the packet Shall be delivered to the Protocol Layer. Note an EOP May be used to prematurely terminate a

Packet e.g., before sending Hard Reset Signaling.

2.4 Hard Reset

Hard Reset Signaling is an ordered set of bytes sent with the purpose to be recognized by the PHY Layer. The Hard

Reset Signaling ordered set is defined as: three RST-1 K-codes followed by one RST-2 K-code (see Table 5-11).

A device Shall perform a Hard Reset when it receives Hard Reset Signaling. After receiving the Hard Reset Signaling, the device Shall reset. If a Valid Hard Reset is not detected then the whole transmission Shall be Discarded.

A Cable Plug Shall perform a Hard Reset when it detects Hard Reset Signaling being sent between the Port Partners. After receiving the Hard Reset Signaling, the device Shall reset.

The procedure for sending Hard Reset Signaling Shall be as follows:

1. If the PHY Layer is currently sending a Message, the Message Shall be interrupted by sending an EOP K-code and the rest of the Message Discarded.
2. If CC is not idle, wait for it to become idle (see Section 5.8.6.1).
3. Wait tInterFrameGap.
4. If CC is still idle send the Preamble followed by the 4 K-codes for Hard Reset Signaling.
5. Disable the channel (i.e., stop sending and receiving), reset the PHY Layer and inform the Protocol Layer that the PHY Layer has been reset.

6. Re-enable the channel when requested by the Protocol Layer.

   Figure 5-5 shows the line format of Hard Reset Signaling which is a Preamble followed by the Hard Reset Ordered Set.

   

   Hard Resets are signaled by an ordered set as defined in Section 5.6.4. Both the sender and recipient Shall cause their

   power supplies to return to their default states (see Section 7.3.12 and Section 7.3.13 for details of Voltage

   transitions). In addition, their respective Protocol Layers Shall be reset as for the Soft Reset. This allows the Attached

   devices to be in a state where they can re-establish USB PD communication. Hard Reset is retried up to

   nHardResetCount times (see also Section 6.6.6 and Section 6.7.3). Note: that even though VBUS drops to vSafe0V

   during a Hard Reset a Sink will not see this as a disconnect since this is expected behavior.

   A Hard Reset Shall Not cause any change to either the Rp/Rd resistor being asserted.

   If there has been a Data Role Swap the Hard Reset Shall cause the Port Data Role to be changed back to DFP for a Port

   with the Rp resistor asserted and UFP for a Port with the Rd resistor asserted.

   When VCONN is supported (see [USB Type-C 2.0]) the Hard Reset Shall cause the Port with the Rp resistor asserted to

   supply VCONN and the Port with the Rd resistor asserted to turn off VCONN.

   In effect the Hard Reset will revert the Ports to their default state based on their CC line resistors. Removing and

   reapplying VCONN from the Cable Plugs also ensures that they re-establish their configuration as either SOP’ or SOP’’

   based on the location of VCONN (see [USB Type-C 2.0]).

   If the Hard Reset is insufficient to clear the error condition, then the Port Shall use Error Recovery mechanisms as

   defined in [USB Type-C 2.0].

   A Sink Shall be able to send Hard Reset signaling regardless of the value of Rp (see Section 5.7).

2.4.1 Cable Plugs and Hard Reset

Cable Plugs Shall Not generate Hard Reset Signaling but Shall monitor for Hard Reset Signaling between the Port

Partners and Shall reset when this is detected (see Section 8.3.3.24.2.2). The Cable Plugs Shall perform the

equivalent of a power cycle returning to their initial power up state. This allows the Attached products to be in a state

where they can re-establish USB PD communication.

2.4.2 Modal Operation and Hard Reset

A Hard Reset Shall cause EPR Mode and all Active Modes to be exited by both Port Partners and any Cable Plugs.

2.5 Cable Reset

Cable Reset Signaling is an ordered set of bytes sent with the purpose to be recognized by the PHY Layer. The Cable

Reset Signaling ordered set is defined as the following sequence of K-codes: RST-1, Sync-1, RST-1, Sync-3 .

Cable Reset Signaling Shall only be sent by the DFP. The Cable Reset Ordered Set is used to reset the Cable Plugs

without the need to Hard Reset the Port Partners. The state of the Cable Plug after the Cable Reset Signaling Shall be

equivalent to power cycling the Cable Plug.

Figure 5-6 shows the line format of Cable Reset Signaling which is a Preamble followed by the Cable Reset Ordered

Set.

Cable Resets are signaled by an ordered set . Both the sender and recipient of Cable Reset

Signaling Shall reset their respective Protocol Layers. The Cable Plugs Shall perform the equivalent of a power cycle

returning to their initial power up state. This allows the Attached products to be in a state where they can re-establish

USB PD communication.

The DFP has to be supplying VCONN prior to a Cable Reset. If VCONN has been turned off the DFP Shall turn on VCONN

prior to generating Cable Reset Signaling. If there has been a VCONN Swap and the UFP is currently supplying VCONN,

the DFP Shall perform a VCONN Swap such that it is supplying VCONN prior to generating Cable Reset Signaling.

Only a DFP Shall generate Cable Reset Signaling. A DFP Shall only generate Cable Reset Signaling within an Explicit

Contract.

A Cable Reset Shall cause all Active Modes in the Cable Plugs to be exited.

2.6 Built in Self-Test (BIST)

The following sections define BIST functionality which Shall be supported.

2.6.1 BIST Carrier Mode

In BIST Carrier Mode, the Physical Layer Shall send out a BMC encoded continuous string of alternating "1"s and “0”

s. This enables the measurement of power supply noise and frequency drift.

Note that this transmission is a purely a sequence of alternating bits and Shall Not be formatted as a Packet.

2.6.2 BIST Test Data

A BIST Test Data Message is used by the Tester to send various Tester generated test patterns to the UUT(Unit Under Test) in order to test the UUT’s receiver. Figure 5-29 shows the Test Data Frame which Shall be sent by the Tester to the UUT. The BIST Message, with a BIST Test Data BIST Data Object consists of a Preamble, followed by SOP*, followed by the Message Header with a data length of 7 Data Objects, followed a BIST Test Data BIST Data Object, followed by 6 Data Objects containing Test data, followed by the CRC and then an EOP.

3、Protocol Layer

3.1 Messages

This specification defines three types of Messages:

• Control Messages that are short and used to manage the Message flow between Port Partners or to exchange

Messages that require no additional data. Control Messages are 16 bits in length.

• Data Messages that are used to exchange information between a pair of Port Partners. Data Messages range from 48 to 240 bits in length.

o There are three types of Data Messages:

▪ Those used to expose capabilities and negotiate power.

▪ Those used for the BIST.

▪ Those that are Vendor Defined.

• Extended Messages that are used to exchange information between a pair of Port Partners. Extended Messages are up to MaxExtendedMsgLen bytes.（260 Byte）

o There are several types of Extended Messages:

▪ Those used for Source and Battery information

▪ Those used for Security.

▪ Those used for Firmware Update.

▪ Those that are vendor defined.

3.1.1 Message Construction

All Messages Shall be composed of a Message Header and a variable length (including zero) data portion. A Message

either originates in the Protocol Layer and is passed to the Physical Layer, or it is received by the Physical Layer and is

passed to the Protocol Layer.

Figure 6-1 illustrates a Control Message as part of a Packet showing the parts are provided by the Protocol and PHY

Layers.

Figure 6-2 illustrates a Data Message as part of a Packet showing the parts are provided by the Protocol and PHY

Layers.

Figure 6-3 illustrates an Extended Message as part of a Packet showing the parts are provided by the Protocol and

PHY Layers.

3.1.1 Message Header

Every Message Shall start with a Message Header as shown in Figure 6-1, Figure 6-2 and Figure 6-3 and as defined in

Table 6 1. The Message Header contains basic information about the Message and the PD Port Capabilities.

The Message Header May be used standalone as a Control Message when the Number of Data Objects field is zero or

as the first part of a Data Message when the Number of Data Objects field is non-zero.

3.1.1.1 Extended

The 1-bit Extended field Shall be set to zero to indicate a Control Message or Data Message and set to one to indicate

an Extended Message.

The Extended field Shall apply to all SOP* Packet types.

3.1.1.2 Number of Data Objects

When the Extended field is set to zero the 3-bit Number of Data Objects field Shall indicate the number of 32-bit

Data Objects that follow the Message Header. When this field is zero the Message is a Control Message and when it is

non-zero, the Message is a Data Message.

The Number of Data Objects field Shall apply to all SOP* Packet types.

When both the Extended bit and Chunked bit are set to one, the Number of Data Objects field Shall indicate the

number of Data Objects in the Message padded to the 4-byte boundary including the Extended Header as part of the

first Data Object.

When the Extended bit is set to one and Chunked bit is set to zero, the Number of Data Objects field Shall be

Reserved. Note that in this case, the message length is determined solely by the Data Size field in the Extended

Message Header.

3.1.1.3 MessageID

The 3-bit MessageID field is the value generated by a rolling counter maintained by the originator of the Message.

The MessageIDCounter Shall be initialized to zero at power-on as a result of a Soft Reset, or a Hard Reset. The

MessageIDCounter Shall be incremented when a Message is successfully received as indicated by receipt of a

GoodCRC Message. Note: the usage of MessageID during testing with BIST Messages is defined in

[USBPDCompliance].

The MessageID field Shall apply to all SOP* Packet types.

3.1.1.4 Port Power Role

The 1-bit Port Power Role field Shall indicate the Port’s present power role:

• 0b Sink

• 1b Source

Messages, such as Ping, and GotoMin, that are only ever sent by a Source, Shall always have the Port Power Role field

set to Source. Similarly, Messages such as the Request Message that are only ever sent by a Sink Shall always have the

Port Power Role field set to Sink.

During the Power Role Swap Sequence, for the initial Source Port, the Port Power Role field Shall be set to Sink in the

PS_RDY Message indicating that the initial Source’s power supply is turned off (see Figure 8-6 and Figure 8-7).

During the Power Role Swap Sequence, for the initial Sink Port, the Port Power Role field Shall be set to Source for

Messages initiated by the Policy Engine after receiving the PS_RDY Message from the initial Source (see Figure 8-6 and

Figure 8-7).

During the Fast Role Swap Sequence, for the initial Source Port, the Port Power Role field Shall be set to Sink in the

PS_RDY Message indicating that VBUS is not being driven by the initial Source and is within vSafe5V (see Figure 8-25).

During the Fast Role Swap Sequence, for the initial Sink Port, the Port Power Role field Shall be set to Source for

Messages initiated by the Policy Engine after receiving the PS_RDY Message from the initial Source (see Figure 8-25).

Note that the GoodCRC Message sent by the initial Sink in response to the PS_RDY Message from the initial Source will

have its Port Power Role field set to Sink since this is initiated by the Protocol Layer. Subsequent Messages initiated

by the Policy Engine, such as the PS_RDY Message sent to indicate that VBUS is ready, will have the Port Power Role

field set to Source.

The Port Power Role field of a received Message Shall Not be verified by the receiver and Shall Not lead to Soft Reset,

Hard Reset or Error Recovery if it is incorrect.

The Port Power Role field Shall only be defined for SOP Packets.

3.1.1.5 Port Data Role

The 1-bit Port Data Role field Shall indicate the Port’s present data role:

• 0b UFP

• 1b DFP

The Port Data Role field Shall only be defined for SOP Packets. For all other SOP* Packets the Port Data Role field is

Reserved and Shall be set to zero.

If a USB Type-C® Port receives a Message with the Port Data Role field set to the same Data Role as its current Data

Role, except for the GoodCRC Message, USB Type-C Error Recovery actions as defined in [USB Type-C 2.0] Shall be

performed.

For a USB Type-C Port the Port Data Role field Shall be set to the default value at Attachment after a Hard Reset: 0b

for a Port with Rd asserted and 1b for a Port with Rp asserted.

In the case that a Port is not USB Communications Capable, at Attachment a Source Port Shall default to DFP and a

Sink Port Shall default to UFP.

3.1.1.6 Cable Plug

The 1-bit Cable Plug field Shall indicate whether this Message originated from a Cable Plug or VPD:

• 0b Message originated from a DFP or UFP.

• 1b Message originated from a Cable Plug or VPD

The Cable Plug field Shall only apply to SOP’ and SOP’’ Packet types.

3.1.1.7 Message Type

The 5-bit Message Type field Shall indicate the type of Message being sent. To fully decode the Message Type, the

Number of Data Objects field is first examined to determine whether the Message is a Control Message or a Data

Message. Then the specific Message Type can be found in Table 6-5 (Control Message) or Table 6-6 (Data Message).

The Message Type field Shall apply to all SOP* Packet types.

3.1.2 Extended Message Header （To be added）

3.2 Control Message

A Message is defined as a Control Message when the Number of Data Objects field in the Message Header is set to 0.

The Control Message consists only of a Message Header and a CRC. The Protocol Layer originates the Control

Messages (i.e., Accept Message, Reject Message etc.).

The Control Message types are specified in the Message Header’s Message Type field (bits 4…0) and are summarized

in Table 6-5. The Sent by column indicates entities which May send the given Message (Source, Sink or Cable Plug);

entities not listed Shall Not issue the corresponding Message. The “Valid Start of Packet” column indicates the

Messages which Shall only be issued in SOP Packets and the Messages which May be issued in SOP* Packets.

3.2.1 GoodCRC Message

The GoodCRC Message Shall be sent by the receiver to acknowledge that the previous Message was correctly received

(i.e., had a good CRC). The GoodCRC Message Shall return the Message’s MessageID so the transmitter can determine

that the correct Message is being acknowledged. The first bit of the GoodCRC Message Shall be returned within

tTransmit after receipt of the last bit of the previous Message.

BIST does not send the GoodCRC Message while in a Continuous BIST Mode (see Section 6.4.3).

3.2.2 Accept Message

The Accept Message is a Valid response in the following cases:

• It Shall be sent by the Source to signal the Sink that the Source is willing to meet the Request Message.

• It Shall be sent by the recipient of the PR_Swap Message to signal that it is willing to do a Power Role Swap and

has begun the Power Role Swap sequence.

• It Shall be sent by the recipient of the DR_Swap Message to signal that it is willing to do a Data Role Swap and has

begun the Data Role Swap sequence.

• It Shall be sent by the recipient of the VCONN_Swap Message to signal that it is willing to do a VCONN Swap and

has begun the VCONN Swap sequence.

• It Shall be sent by the recipient of the FR_Swap Message to indicate that it has begun the Fast Role Swap

sequence.

• It Shall be sent by the recipient of the Soft_Reset Message to indicate that it has completed its Soft Reset.

The Accept Message Shall be sent within tReceiverResponse of the receipt of the last bit of the Message (see Section

6.6.2).

3.2.3 Reject Message

The Reject Message is a Valid response in the following cases:

• It Shall be sent to signal the Sink that the Source is unable to meet the Request Message. This May be due an

Invalid request or because the Source can no longer provide what it previously Advertised.

• It Shall be sent by the recipient of a PR_Swap Message to indicate it is unable to do a Power Role Swap.

• It Shall be sent by the recipient of a DR_Swap Message to indicate it is unable to do a Data Role Swap.

• It Shall be sent by the recipient of a VCONN_Swap Message that is not presently the VCONN Source, to indicate it is

unable to do a VCONN Swap.

The Reject Message Shall be sent within tReceiverResponse of the receipt of the last bit of Message (see Section

6.6.2).

Note: the Reject Message is not a Valid response when a Message is not supported. In this case the Not_Supported

Message is returned (see Section 6.3.16).

3.2.4 PS_RDY Message

The PS_RDY Message Shall be sent by the Source (or by both the new Sink and new Source during the Power Role

Swap sequence or Fast Role Swap sequence) to indicate its power supply has reached the desired operating condition

(see Section 8.3.2.2).

3.2.5 Get_Source_Cap Message

The Get_Source_Cap (Get Source Capabilities) Message May be sent by a Port to request the Source Capabilities and

Dual-Role Power capability of its Port Partner (e.g., Dual-Role Power capable). The Port Shall respond by returning a

Source_Capabilities Message (see Section 6.4.1.1.1).

3.2.6 Get_Sink_Cap Message

The Get_Sink_Cap (Get Sink Capabilities) Message May be sent by a Port to request the Sink Capabilities and DualRole Power capability of its Port Partner (e.g., Dual-Role Power capable). The Port Shall respond by returning a Sink_Capabilities Message (see Section 6.4.1.1.2).

3.2.7 DR_Swap Message

The DR_Swap Message is used to exchange DFP and UFP operation between Port Partners while maintaining the

direction of power flow over VBUS. The DR_Swap process can be used by Port Partners whether or not they support

USB Communications capability. A DFP that supports USB Communication Capability starts as the USB Host on

Attachment. A UFP that supports USB Communication Capability starts as the USB Device on Attachment.

[USB Type-C 2.0] DRDs Shall have the capability to perform a Data Role Swap from the PE_SRC_Ready or

PE_SNK_Ready states. DFPs and UFPs May have the capability to perform a Data Role Swap from the PE_SRC_Ready

or PE_SNK_Ready states. A Data Role Swap Shall be regarded in the same way as a cable Detach/re-Attach in relation

to any USB communication which is ongoing between the Port Partners. If there are any Active Modes between the

Port Partners when a DR_Swap Message is a received, then a Hard Reset Shall be performed (see Section 6.4.4.3.4). If

the Cable Plug has any Active Modes then the DFP Shall Not issue a DR_Swap Message and Shall cause all Active

Modes in the Cable Plug to be exited before accepting a DR Swap request.

The Source of VBUS and VCONN Source Shall remain unchanged as well as the Rp/Rd resistors on the CC wire during the

Data Role Swap process.

The DR_Swap Message May be sent by either Port Partner. The recipient of the DR_Swap Message Shall respond by

sending an Accept Message, Reject Message or Wait Message.

• If an Accept Message is sent, the Source and Sink Shall exchange operational roles.

• If a Reject Message is sent, the requester is informed that the recipient is unable, or unwilling, to do a Data Role

Swap and no action Shall be taken.

• If a Wait Message is sent, the requester is informed that a Data Role Swap might be possible in the future but that

no immediate action Shall be taken.

Before a Data Role Swap the initial DFP Shall have its Port Data Role bit set to DFP, and the initial UFP Shall have its

Port Data Role bit set to UFP.

After a successful Data Role Swap the DFP/Host Shall become the UFP/Device and vice-versa; the new DFP Shall have

its Port Data Role bit set to DFP, and the new UFP Shall have its Port Data Role bit set to UFP. Where USB

Communication is supported by both Port Partners a USB data connection Should be established according to the new

data roles.

If the Data Role Swap, after having been accepted by the Port Partner, is subsequently not successful, in order to

attempt a re-establishment of the connection on the CC Wire, USB Type-C Error Recovery actions, such as disconnect,

as defined in [USB Type-C 2.0] will be necessary.

3.2.8 PR_Swap Message

The PR_Swap Message May be sent by either Port Partner to request an exchange of power roles. The recipient of the

Message Shall respond by sending an Accept Message, Reject Message or Wait Message.

• If an Accept Message is sent, the Source and Sink Shall do a Power Role Swap.

• If a Reject Message is sent, the requester is informed that the recipient is unable, or unwilling, to do a Power Role

Swap and no action Shall be taken.

• If a Wait Message is sent, the requester is informed that a Power Role Swap might be possible in the future but

that no immediate action Shall be taken.

After a successful Power Role Swap the Port Partners Shall reset their respective Protocol Layers (equivalent to a Soft

Reset): resetting their MessageIDCounter, RetryCounter and Protocol Layer state machines before attempting to

establish an Explicit Contract. At this point the Source Shall also reset its CapsCounter.

The Source Shall have Rp asserted on the CC wire and the Sink Shall have Rd asserted on the CC wire as defined in

[USB Type-C 2.0]. When performing a Power Role Swap from Source to Sink, the Port Shall change its CC Wire

resistor from Rp to Rd. When performing a Power Role Swap from Sink to Source, the Port Shall change its CC Wire

resistor from Rd to Rp. The DFP (Host), UFP (Device) roles and VCONN Source Shall remain unchanged during the

Power Role Swap process.

Note: during the Power Role Swap process the initial Sink does not disconnect even though VBUS drops below vSafe5V.

3.2.9 VCONN_Swap Message

The VCONN_Swap Message Shall be supported by any Port that can operate as a VCONN Source.

The VCONN_Swap Message May be sent by either Port Partner to request an exchange of VCONN Source. The recipient

of the Message Shall respond by sending an Accept Message, Reject Message, Wait Message or Not_Supported

Message.

• If an Accept Message is sent, the Port Partners Shall perform a VCONN Swap. The new VCONN Source Shall send a

PS_RDY Message within tVCONNSourceOn to indicate that it is now sourcing VCONN. The initial VCONN Source

Shall cease sourcing VCONN within tVCONNSourceOff of receipt of the last bit of the EOP of the PS_RDY Message.

• If a Reject Message is sent, the requester is informed that the recipient is unable, or unwilling, to do a VCONN Swap

and no action Shall be taken. A Reject Message Shall only be sent by the Port that is not presently the Vconn

Source in response to a VCONN_Swap Message. The Port that is presently the Vconn Source Shall Not send a

Reject Message in response to VCONN_Swap Message.

• If a Wait Message is sent, the requester is informed that a VCONN Swap might be possible in the future but that no

immediate action Shall be taken. A Wait Message Shall only be sent by the Port that is not presently the Vconn

Source in response to a VCONN_Swap Message. The Port that is presently the Vconn Source Shall Not send a

Wait Message in response to VCONN_Swap Message.

• If a Not_Supported Message is sent, the requester is informed that VCONN Swap is not supported. The Port that is

not presently the Vconn Source May turn on VCONN when a Not_Supported Message is received in response to a

VCONN_Swap Message.

The DFP (Host), UFP (Device) roles and Source of VBUS Shall remain unchanged as well as the Rp/Rd resistors on the

CC wire during the VCONN Swap process.

Note: VCONN Shall be continually sourced during the VCONN Swap process in order to maintain power to the Cable

Plug(s) i.e., make before break.

Before communicating with a Cable Plug a Port Shall ensure that it is the VCONN Source and that the Cable Plugs are

powered, by performing a VCONN swap if necessary. Since it cannot be guaranteed that the present VCONN Source is

supplying VCONN, the only means to ensure that the Cable Plugs are powered is for a Port wishing to communicate

with a Cable Plug to become the VCONN Source. If a Not_Supported Message is returned in response to the

VCONN_Swap Message, then the Port is allowed to become the VCONN Source until a Hard Reset or Detach.

A VCONN Source that is also a Source can attempt to send a Discover Identity Command using SOP’ to a Cable Plug

prior to the establishment of an Explicit Contract.

Note: even when it is presently the VCONN Source, the Sink is not permitted to initiate an AMS with a Cable Plug unless

Rp is set to SinkTxOk (see Section 6.9).

3.2.10 Soft Reset Message

A Soft_Reset Message May be initiated by either the Source or Sink to its Port Partner requesting a Soft Reset. The

Soft_Reset Message Shall cause a Soft Reset of the connected Port Pair (see Section 6.8.1). If the Soft_Reset Message

fails a Hard Reset Shall be initiated within tHardReset of the last CRCReceiveTimer expiring after nRetryCount

retries have been completed.

A Soft_Reset Message is used to recover from Protocol Layer errors; putting the Message counters to a known state in

order to regain Message synchronization. The Soft_Reset Message has no effect on the Source or Sink; that is the

previously negotiated direction. Voltage and current remain unchanged. Modal Operation is unaffected by Soft Reset.

However after a Soft Reset has completed, an Explicit Contract negotiation occurs, in order to re-establish PD

Communication and to bring state operation for both Port Partners back to either the PE_SNK_Ready or

PE_SRC_Ready states as appropriate (see Section 8.3.3.4).

A Soft_Reset Message May be sent by either the Source or Sink when there is a Message synchronization error. If the

error is not corrected by the Soft Reset, Hard Reset Signaling Shall be issued (see Section 6.8).

A Soft_Reset Message Shall be targeted at a specific entity depending on the type of SOP* Packet used. Soft_Reset

Messages sent using SOP Packets Shall Soft Reset the Port Partner only. Soft_Reset Messages sent using SOP’/SOP’’

Packets Shall Soft Reset the corresponding Cable Plug only.

After a VCONN Swap the VCONN Source needs to reset the Cable Plug’s Protocol Layer in order to ensure MessageID

synchronization. If after a VCONN Swap the VCONN Source wants to communicate with a Cable Plug using SOP’ Packets,

it Shall issue a Soft_Reset Message using a SOP’ Packet in order to reset the Cable Plug’s Protocol Layer. If the VCONN

Source wants to communicate with a Cable Plug using SOP’’ Packets, it Shall issue a Soft_Reset Message using a SOP’’

Packet in order to reset the Cable Plug’s Protocol Layer.

3.2.11 Get_Status Message

The Get_Status Message is sent by a Port using SOP to request the Port Partner’s present status.

The Source or Sink Shall respond by returning a Status Message (see Section 6.5.2). A Port that receives an Alert

Message (see Section 6.4.6) indicates that the Source or Sink’s Status has changed and Should be re-read using a

Get_Status Message.

The Get_Status Message May also be sent to an Active Cable to get its present status using SOP’/SOP’’.

The Active Cable Shall respond by returning a Status Message (see Section 6.5.2).

3.2.12 FR_Swap Message

The FR_Swap Message Shall be sent by the new Source within tFRSwapInit after it has detected a Fast Role Swap

signal (see Section 5.8.6.3 and Section 6.6.17.3). The Fast Role Swap AMS is necessary to apply Rp to the new Source

and Rd to the new Sink and to re-synchronize the state machines. The tFRSwapInit time Shall be measured from the

time the FRS signal has been sent for tFRSwapRx (max) until the last bit of the EOP of the FR_Swap Message has been

transmitted by the Physical Layer.

The recipient of the FR_Swap Message Shall respond by sending an Accept Message.

After a successful Fast Role Swap the Port Partners Shall reset their respective Protocol Layers (equivalent to a Soft

Reset): resetting their MessageIDCounter, RetryCounter and Protocol Layer state machines before attempting to

establish an Explicit Contract. At this point the Source Shall also reset its CapsCounter.

This ensures that only the Cable Plug responds with a GoodCRC Message to the Discover Identity Command.

Prior to the Fast Role Swap AMS the new Source Shall have Rd asserted on the CC wire and the new Sink Shall have

Rp asserted on the CC wire. Note that this is an incorrect assignment of Rp/Rd (since Rp follows the Source and Rd

follows the Sink as defined in [USB Type-C 2.0]) that is corrected by the Fast Role Swap AMS.

During the Fast Role Swap AMS the new Source Shall change its CC Wire resistor from Rd to Rp and the new Sink

Shall change its CC Wire resistor from Rp to Rd. The DFP (Host), UFP (Device) roles and VCONN Source Shall remain

unchanged during the Fast Role Swap process.

The initial Source Should avoid being the VCONN source (by using the VCONN Swap process) whenever not actively

communicating with the cable, since it is difficult for the initial Source to maintain VCONN power during the Fast Role

Swap process.

Note: during the Fast Role Swap process the initial Sink does not disconnect even though VBUS drops below vSafe5V.

3.2.13 Get_Source_Info Message

The Get_Source_Info Message is sent by a Port to request the type, maximum capabilities and present capabilities of

the port when it is operating as a Source. The port Shall respond by returning the Source_Info Message.

3.3 Data Message

A Data Message Shall consist of a Message Header and be followed by one or more Data Objects. Data Messages are

easily identifiable because the Number of Data Objects field in the Message Header is a non-zero value.

There are several types of Data Objects:

• BIST Data Object (BDO) used for PHY Layer compliance testing.

• Power Data Object (PDO) used to expose a Source Port’s power capabilities or a Sink’s power requirements.

• Request Data Object (RDO) used by a Sink Port to negotiate a Contract.

• Vendor Defined Data Object (VDO) used to convey vendor specific information.

• Battery Status Data Object (BSDO) used to convey Battery status information.

• Alert Data Object (ADO) used to indicate events occurring on the Source or Sink.

The type of Data Object being used in a Data Message is defined by the Message Header’s Message Type field and is

summarized in Table 6-6. The Sent by column indicates entities which May send the given Message (Source, Sink or

Cable Plug); entities not listed Shall Not issue the corresponding Message. The Valid Start of Packet column indicates

the Messages which Shall only be issued in SOP Packets and the Messages which May be issued in SOP* Packets.