SPMU380 July   2026 TPS25730A

 

  1.   1
  2. 1Read This First
    1. 1.1 About This Manual
    2. 1.2 Notational Conventions
    3. 1.3 Glossary
    4. 1.4 Related Documents
    5. 1.5 Support Resources
    6. 1.6 Trademarks
  3. 2Introduction
    1. 2.1 Purpose and Scope
    2. 2.2 PD Controller Host Interface Description
      1. 2.2.1 Overview
    3. 2.3 Unique Address Interface
      1. 2.3.1 Unique Address Interface Protocol
  4. 3PD Controller Policy Modes
    1. 3.1 Overview
    2. 3.2 Sink Policy Mode
  5. 4Register Overview
    1. 4.1 TPS25730A Registers
  6. 54CC Task Detailed Descriptions
    1. 5.1 Overview
    2. 5.2 PD Message Tasks
      1. 5.2.1 'GSrC' - PD Get Source Capabilities
      2. 5.2.2 'GPPI' - PD Get Port Partner Information
      3. 5.2.3 'MBRd' - Message Buffer Read
    3. 5.3 System Tasks
      1. 5.3.1 'ANeg' - Auto Negotiate Sink Update
      2. 5.3.2 'DBfg' - Clear Dead Battery Flag
  7. 6User Reference
    1. 6.1 AUTO_NEGOTIATE_SINK Register
      1. 6.1.1 AUTO_NEGOTIATE_SINK Usage Example 1
      2. 6.1.2 AUTO_NEGOTIATE_SINK Usage Example 2
      3. 6.1.3 AUTO_NEGOTIATE_SINK Usage Example 3
      4. 6.1.4 AUTO_NEGOTIATE_SINK Usage Example 4
  8. 7Revision History

'GPPI' - PD Get Port Partner Information

The 'GPPI' Task can be used to cause the PD controller to issue these types of USB PD Get messages:

  • Get_Source_Cap_Extended (control message)
  • Get_Status (Control message)
  • Get_Battery_Status (Extended message)
  • Get_Battery_Cap (Extended message)
  • Get_Manufacturer_Info (Extended message)

The PD controller does not have dedicated registers to store the response to these messages. The host must get that response from the DATAX register associated with this Task.

The host must NOT use 'GPPI' to send Get_Source_Capabilities messages, because the USB PD spec requires specific actions be taken by the PD controller any time those messages are received. While executing the 'GPPI' Task, the PD controller does not parse the returned message to carry out those checks. Instead, the host must use 'GSrC' to send Get_Source_Capabilities messages.

Table 5-3 'GPPI' - Send a USB PD Get* Message
DescriptionThe 'GPPI' Task instructs PD Controller to issue a specific USB PD message to the Port Partner at the first opportunity while maintaining policy engine compliance.
INPUT DATAXBitNameDescription
15Reserved
14:13FrameType00b SOP
01bSOP'
10bSOP''
11bReserved
12:8NumBytes
7Reserved
6:5MessageCategory00b Control message (no payload)
01bData message (requires payload)
10bExtended message (requires payload)
11bReserved
4:0MessageTypeThis field must be the MessageType as defined in the USB PD specification. It specifies the Type of message the PD controller will send.
OUTPUT DATAXByte 1: Standard Task Return Code. See also Table 5-1.
Task CompletionThe 'GPPI' Task completes either when the appropriate message is received or the Task otherwise fails.The 'GPPI' Task shall be considered rejected if:
  • Sending the requested message can violate the USB PD spec.
  • The PortPartner replies with a Reject or Not_Supported message.
The 'GPPI' Task shall be considered timed-out if:
  • The requested message is sent, GoodCRC'ed and the recipient (Port Partner or Cable Plug) fails to respond within the time required by the PD spec.
  • A PD Hard Reset or a disconnection happens before the Task completes.
The 'GPPI' Task shall be considered successful if:
  • The requested message is sent, GoodCRC'ed and an appropriate response is received and processed.

The 'GPPI' Task shall be aborted when the Rx Buffer is locked. The Rx Buffer is locked after data from a receive message is placed in the DATAX register. The Rx Buffer is unlocked after disconnect and by the 'MBRd' Task.

Side Effects

If the PD controller is in the sink power role and it reads Rp = SinkTxNG, it will wait until Rp = SinkTxOK before initiating the atomic message sequence requested by this 'GPPI' Task. This can cause an non-deterministic delay in completing the Task.

Additional InformationThe PD controller will continue trying to execute this Task until it times out or aborts as described above. Some scenarios where this can happen are:
  • The PD controller with a sink power role (that is PresentRole = Sink) is required to wait for Rp = SinkTxOK before initiating an Atomic Message Sequence. The PD controller will continue waiting for Rp = SinkTxOK until it is able to send the appropriate message required for this 'GPPI' Task.

While executing the 'GPPI' Task, the PD controller uses the same shared buffer that is used to store other extended messages. Therefore, the host must not use the 'GPPI' Task when any other atomic message sequence is ongoing.

To read the PD response received as a result of issuing the 'GPPI' Task after it is completed, the host must use the 'MBRd' 4CC command. The 'MBRd' Task must also be used to unlock the Rx Buffer for other incoming message.