100 watts via USB or how Power Delivery works
After reading this post and the discussion accompanying it, I decided to try to clarify what USB Power Delivery is and how it actually works. Unfortunately, I got the impression that most of the discussion participants perceive 100 watts via USB too literally, and they do not fully understand what this stands at the level of schematics and protocols.
So, briefly - the main points:
Under the cut - the details.
USB Power Delivery works with six types of connectors:
')
Accordingly, the following types of compounds are acceptable in pairs.
Separately, it is worth noting that the specification directly prohibits perversions with several connectors on one side of the connecting cable, which is quite logical, given currents up to 100 watts. On the other hand, the use of adapters and adapters is not forbidden, provided that they correspond to the power supply profile, and do not short the cable shield to its ground.
After certification, USB PD ports are marked as follows:
This logo informs you about the USB version (2.0 or 3.0 SuperSpeed), as well as the power profiles that this port supports. The value of "I" means the consumed profile necessary for the full functioning of the device, and the value "O" which port can provide which profile. Port marking examples:
The USB PD defines a circuit diagram of the physical connection organization via cable as follows:
As can be seen from the diagram, USB PD also requires that the power drop / surge determination schemes as well as methods for determining a dead battery for one of the parties cannot be powered from its internal source, both in the source and in the receiver.
The following algorithms are proposed as algorithms for determining a dead battery. If one of the sides sets a resistance of 1 kOhm between the screen and the ground, this indicates that its battery is low. In such a situation, the other side assumes the role of a source and begins to give the minimum 5V in order to give power to the opposing side through VBus and begin exchanging messages via the USB PD protocol.
As mentioned earlier, the USB PD protocol uses the VBus line for messaging. Below is a block diagram defining the key functional elements of the transmitter:
And accordingly, the same block diagram for the receiver:
Serialized encoding 4b5b and decoding 5b4b implies that all data on the bus, except for the packet preamble, is transmitted in five-bit sequences in accordance with the coding table defined by the standard. Each such sequence encodes either one of the 16 digits (0x00..0x0F), or the start / sync / reset signals and the end of the packet. Thus, the transmission of one byte takes 10 bits, the 16-bit word takes 20 bits and the 32-bit double word takes 40 bits, etc.
USB PD protocol is based on successive request-response pairs. Requests and responses are forwarded using packets. Packages consist of a preamble (preparatory phase for transmission), the start of an SOP packet (three Sync-1 signals and final Sync-2 encoded in 4b5b), a header, 0..N bytes of payload, a checksum (CRC-32) and an end signal packet (single EOP):
As mentioned above, the preamble is not encoded in 4b5b. SOP, CRC and EOP are encoded at 4b5b at the physical layer, the header and payload are encoded at the logical protocol level.
The bus is reset by sending three RST1 signals and a terminating RST2 signal, in accordance with coding 4b5b.
All USB PD messages consist of a header and a portion of data of arbitrary length. Messages are either generated at the logical protocol level and then forwarded to the physical layer, or received at the physical layer and then forwarded to the logical protocol level.
The message header has a fixed length of 16 bits and consists of the following fields:
Messages are of two types - control (control) and information (data).
Control messages consist of header and CRC only. The number of data objects for such messages is always set to 0. The types of USB PD control messages are presented in the table below:
Separately, it should be mentioned that the fields are tSourceActivity , tSinkRequest , etc. - these are constants, the values ​​of which are globally defined by the specification itself in a separate chapter. This was done because they were determined empirically as a result of prototyping, and the optimal values ​​found were simply substituted into a separate chapter in order not to scour the entire specification.
This type of messages is designed to obtain detailed information about the source or receiver, as well as to transfer the requested power supply characteristics - current, voltage, etc. Informational messages always contain a non-zero value in the “Number of Data Objects” field.
The specification defines four types of informational messages:
The types of informational messages are encoded in the "Message Type" field of the message header as follows:
The source port is always required to communicate its characteristics to the receiver by transmitting a series of 32-bit PDO objects. The information transmitted through these objects is used to determine the capabilities of the source, including the ability to operate in receiver mode.
Performance reports are presented as one or more objects following the heading:
Performance reports are transmitted:
Each PDO object must characterize a separate power supply element included in the device at the maximum allowable voltage values ​​for it. For example, the built-in battery 2.8-4.1V, stationary power supply 12V, etc. All power supply elements must support at least 5V and, accordingly, each source must have at least one PDO corresponding to a profile with 5V characteristics.
PDO corresponding to an element with a constant type of power supply 5V should always go first in the chain of objects.
PDO object structure:
Different specifications are available for each type of power supply.
Permanent type of power supply, constant voltage. The source must have at least one such element:
A programmable type of power supply, the voltage can be regulated by requests between the minimum and maximum:
Variable type of power supply, the voltage can vary within the specified limits of the absolute minimum and absolute maximum, but can not be regulated:
Battery , this type is used to designate batteries that can be directly connected to the VBus line:
Request messages are transmitted by the receiver to the source to transmit its requirements in the phase of establishing an agreement on power supply. This message is sent in response to a performance message and must contain one and only one data request object, RDO, which describes information about the required power characteristics for the receiver.
This request has two types, depending on the addressable type of power supply element transmitted in the message about the characteristics of the source. For requests to a constant-power or variable-type power cell, or a battery, the fields “Operating Current / Power” and ”Total Current / Prog Voltage” are interpreted in one way, and for inquiries to a programmable type element - in another way, as in this case the voltage is also requested. and current strength.
RDO object structure:
In my opinion, this information is enough to get a good idea of ​​how USB Power Delivery works. I deliberately did not go deep into the jungle associated with timers, counters and error handling.
As mentioned above, Power Delivery is an independent subsystem that functions in parallel and independently of canonical USB. However, in cases where the devices implement both protocols - and USB and Power Delivery, the specification recommends the implementation of the so-called. System Policy Manager or SPM, a component that can control USB PD equipment through traditional USB requests.
For systems with SPM support, the specification recommends that you provide PD information using special types of USB descriptors. I do not consider it necessary to go into them in detail, just to list their names:
To control USB Power Delivery via USB requests, in case the device supports the Power Delivery class, the specification offers commands that can be used to transfer PD requests and objects via USB, that is, via the data bus. The summary table is given below:
I hope that this post, I warmed the interest of the public to USB Power Delivery. Modestly, I note that the author is directly related to this specification, so he is ready to answer any questions about Power Delivery in particular, and USB in general.
Sincerely.
So, briefly - the main points:
- USB PD defines 5 standard power supply profiles - up to 5V @ 2A, up to 12V@1.5, up to 12V @ 3A, up to 12-20V @ 3A and up to 12-20V@4.75-5A
- Cables and ports for Power Delivery are certified and have additional pins in the connector
- The type of cable and its correspondence to the profile are determined automatically through additional pins and the definition of the type of USB connector (micro, standard, A, B, etc.)
- Regular USB cables (not Power Delivery) are certified only by the first profile up to 5V @ 2A
- When connected, the roles are distributed between the one who gives the current ( Source / Source ) and who consumes ( Sink / Receiver )
- The source and the receiver exchange messages using a special protocol that runs in parallel with traditional USB
- The protocol uses a pair of VBus / GND as a physical carrier. That is why Power Delivery does not depend on the main USB protocol and is backward compatible with USB 2.0 and 3.0.
- Using messages, the source and receiver can change roles at any time, change the amperage and / or voltage, go into hibernation or wake up, etc.
- Optionally, devices can support PD management via traditional USB requests, descriptors, etc.
Under the cut - the details.
About males About cables
USB Power Delivery works with six types of connectors:
')
Accordingly, the following types of compounds are acceptable in pairs.
- USB 3.0 PD Standard-A <-> USB 3.0 PD Standard-B plug
- USB 3.0 PD Standard-A <-> USB 3.0 PD Micro-B plug
- USB 3.0 PD Micro-A <-> USB 3.0 PD Micro-B plug
- USB 3.0 PD Micro-A <-> USB 3.0 PD Standard-B plug
- USB 2.0 PD Standard-A <-> USB 2.0 PD Standard-B plug
- USB 2.0 PD Standard-A <-> USB 2.0 PD Micro-B plug
- USB 2.0 PD Micro-A <-> USB 2.0 PD Micro-B plug
- USB 2.0 PD Micro-A <-> USB 2.0 PD Standard-B plug
Separately, it is worth noting that the specification directly prohibits perversions with several connectors on one side of the connecting cable, which is quite logical, given currents up to 100 watts. On the other hand, the use of adapters and adapters is not forbidden, provided that they correspond to the power supply profile, and do not short the cable shield to its ground.
About ports
After certification, USB PD ports are marked as follows:
This logo informs you about the USB version (2.0 or 3.0 SuperSpeed), as well as the power profiles that this port supports. The value of "I" means the consumed profile necessary for the full functioning of the device, and the value "O" which port can provide which profile. Port marking examples:
- The first port supports USB2. It can provide power over Profile 1 (2A @ 5V) and uses Profile 3 (5V @ 2A or 12V @ 3A) to function fully. For example, a port for a tablet or netbook.
- The second port supports USB2. It can provide power over Profile 2 (2A @ 5V or 12V@1.5A) and uses Profile 4 (5V @ 2A or 12V @ 3A or 20V @ 3A) for proper functioning. For example, a port for a laptop or laptop.
- The third port supports USB3. It only gives power to Profile 1 (5V @ 2A). He himself is not powered by VBus. For example, the port of the desktop, monitor, TV, etc.
- The fourth port supports USB3. As in the first example, it can provide power over Profile 1 (5V @ 2A) and itself requires power over Profile 3 in order to fully function (5V @ 2A or 12V @ 3A). Example think up yourself :)
Physical channel
The USB PD defines a circuit diagram of the physical connection organization via cable as follows:
As can be seen from the diagram, USB PD also requires that the power drop / surge determination schemes as well as methods for determining a dead battery for one of the parties cannot be powered from its internal source, both in the source and in the receiver.
The following algorithms are proposed as algorithms for determining a dead battery. If one of the sides sets a resistance of 1 kOhm between the screen and the ground, this indicates that its battery is low. In such a situation, the other side assumes the role of a source and begins to give the minimum 5V in order to give power to the opposing side through VBus and begin exchanging messages via the USB PD protocol.
As mentioned earlier, the USB PD protocol uses the VBus line for messaging. Below is a block diagram defining the key functional elements of the transmitter:
And accordingly, the same block diagram for the receiver:
Serialized encoding 4b5b and decoding 5b4b implies that all data on the bus, except for the packet preamble, is transmitted in five-bit sequences in accordance with the coding table defined by the standard. Each such sequence encodes either one of the 16 digits (0x00..0x0F), or the start / sync / reset signals and the end of the packet. Thus, the transmission of one byte takes 10 bits, the 16-bit word takes 20 bits and the 32-bit double word takes 40 bits, etc.
Logical channel
USB PD protocol is based on successive request-response pairs. Requests and responses are forwarded using packets. Packages consist of a preamble (preparatory phase for transmission), the start of an SOP packet (three Sync-1 signals and final Sync-2 encoded in 4b5b), a header, 0..N bytes of payload, a checksum (CRC-32) and an end signal packet (single EOP):
As mentioned above, the preamble is not encoded in 4b5b. SOP, CRC and EOP are encoded at 4b5b at the physical layer, the header and payload are encoded at the logical protocol level.
The bus is reset by sending three RST1 signals and a terminating RST2 signal, in accordance with coding 4b5b.
Protocol
All USB PD messages consist of a header and a portion of data of arbitrary length. Messages are either generated at the logical protocol level and then forwarded to the physical layer, or received at the physical layer and then forwarded to the logical protocol level.
The message header has a fixed length of 16 bits and consists of the following fields:
Messages are of two types - control (control) and information (data).
Control messages
Control messages consist of header and CRC only. The number of data objects for such messages is always set to 0. The types of USB PD control messages are presented in the table below:
Separately, it should be mentioned that the fields are tSourceActivity , tSinkRequest , etc. - these are constants, the values ​​of which are globally defined by the specification itself in a separate chapter. This was done because they were determined empirically as a result of prototyping, and the optimal values ​​found were simply substituted into a separate chapter in order not to scour the entire specification.
Informational messages
This type of messages is designed to obtain detailed information about the source or receiver, as well as to transfer the requested power supply characteristics - current, voltage, etc. Informational messages always contain a non-zero value in the “Number of Data Objects” field.
The specification defines four types of informational messages:
- Power Data Objec t (PDO) - used to describe the characteristics of the source port or receiver requirements
- Request Data Object (RDO) - used by the receiver port to establish agreement on power characteristics
- BIST (Built In Self Test) Data Object (BDO) - used to test connectivity for compliance with the specifications for a physical connection
- Vendor Data Object (VDO) - used to transfer non-standard, additional or other proprietary information defined by the equipment manufacturer and beyond the specifications of the USB PD.
The types of informational messages are encoded in the "Message Type" field of the message header as follows:
Performance Report
The source port is always required to communicate its characteristics to the receiver by transmitting a series of 32-bit PDO objects. The information transmitted through these objects is used to determine the capabilities of the source, including the ability to operate in receiver mode.
Performance reports are presented as one or more objects following the heading:
Performance reports are transmitted:
- From the source to the receiver after a certain time interval, with direct connection of the cable. The source must continue to send messages for one minute after connecting until a successful power supply agreement is established, or the receiver does not return the RDO with the Capability Mismatch flag - a mismatch of characteristics.
- From source to receiver for the purpose of enforcing a re-establishment of a power supply agreement or a change in characteristics.
- In response to control messages Get_Source_Cap or Get_Sink_Cap
Each PDO object must characterize a separate power supply element included in the device at the maximum allowable voltage values ​​for it. For example, the built-in battery 2.8-4.1V, stationary power supply 12V, etc. All power supply elements must support at least 5V and, accordingly, each source must have at least one PDO corresponding to a profile with 5V characteristics.
PDO corresponding to an element with a constant type of power supply 5V should always go first in the chain of objects.
PDO object structure:
Different specifications are available for each type of power supply.
Permanent type of power supply, constant voltage. The source must have at least one such element:
A programmable type of power supply, the voltage can be regulated by requests between the minimum and maximum:
Variable type of power supply, the voltage can vary within the specified limits of the absolute minimum and absolute maximum, but can not be regulated:
Battery , this type is used to designate batteries that can be directly connected to the VBus line:
Request Message
Request messages are transmitted by the receiver to the source to transmit its requirements in the phase of establishing an agreement on power supply. This message is sent in response to a performance message and must contain one and only one data request object, RDO, which describes information about the required power characteristics for the receiver.
This request has two types, depending on the addressable type of power supply element transmitted in the message about the characteristics of the source. For requests to a constant-power or variable-type power cell, or a battery, the fields “Operating Current / Power” and ”Total Current / Prog Voltage” are interpreted in one way, and for inquiries to a programmable type element - in another way, as in this case the voltage is also requested. and current strength.
RDO object structure:
In my opinion, this information is enough to get a good idea of ​​how USB Power Delivery works. I deliberately did not go deep into the jungle associated with timers, counters and error handling.
Interaction with traditional USB
As mentioned above, Power Delivery is an independent subsystem that functions in parallel and independently of canonical USB. However, in cases where the devices implement both protocols - and USB and Power Delivery, the specification recommends the implementation of the so-called. System Policy Manager or SPM, a component that can control USB PD equipment through traditional USB requests.
For systems with SPM support, the specification recommends that you provide PD information using special types of USB descriptors. I do not consider it necessary to go into them in detail, just to list their names:
- Power Delivery Capability Descriptor , is part of the BOS descriptor and reports whether the device supports battery charging via USB, whether it supports the USB PD standard, whether it can act as a power source, and whether it can be a receiver. In addition, this descriptor contains information on the number of source ports, receiver ports, and the version of supported USB Battery Charging and Power Delivery specifications.
- Battery Info Capability Descriptor , required for all devices that have declared the battery as one of the power supplies. It contains information about the name, serial number and manufacturer of the battery, its capacity, as well as the threshold values ​​of the current in a charged and discharged state.
- PD Consumer Port Capability Descriptor is required for all devices that have declared support for at least one receiver port. Contains information on support for Power Delivery and Battery Charging standards, minimum and maximum voltage, operating power, maximum peak power and maximum time it can consume this peak power
- PD Provider Port Capability Descriptor is required for all devices that have declared support for at least one power supply port. It contains information on the support of Power Delivery and Battery Charging standards, as well as a list of all PDO objects that characterize the power supply elements available to the device.
- PD Power Requirement Descriptor , required for all USB PD receiver devices. Each device must return at least one such descriptor as part of the configuration descriptor. This descriptor should go right after the first interface descriptor. In the case when there are several, it must go after each first function interface descriptor if IAD is used, or in the case of a composite device without IAD, immediately after each interface descriptor, and before endpoint descriptors.
To control USB Power Delivery via USB requests, in case the device supports the Power Delivery class, the specification offers commands that can be used to transfer PD requests and objects via USB, that is, via the data bus. The summary table is given below:
Conclusion
I hope that this post, I warmed the interest of the public to USB Power Delivery. Modestly, I note that the author is directly related to this specification, so he is ready to answer any questions about Power Delivery in particular, and USB in general.
Sincerely.
Source: https://habr.com/ru/post/166661/
All Articles