SLVUCR7 September   2024 TPS26750

 

  1.   1
  2.   Read This First
    1.     About This Manual
    2.     National Conventions
    3.     Glossary
    4.     Related Documents
    5.     Support Resources
    6.     Trademarks
  3. 1Introduction
    1. 1.1 Introduction
      1. 1.1.1 Purpose and Scope
    2. 1.2 PD Controller Host Interface Description
      1. 1.2.1 Overview
      2. 1.2.2 Register and field notation
    3. 1.3 Unique Address Interface
      1. 1.3.1 Unique Address Interface Protocol
  4. 2PD Controller Policy Modes
    1. 2.1 Overview
    2. 2.2 Source Policy Mode
    3. 2.3 Sink Policy Mode
  5. 3Register Overview
  6. 4TPS26750 Registers
  7. 54CC Task Detailed Descriptions
    1. 5.1 Overview
    2. 5.2 CPU Control Tasks
      1. 5.2.1 'Gaid' - Return to normal operation
      2. 5.2.2 'GAID' - Cold reset request
    3. 5.3 PD Message Tasks
      1. 5.3.1  'SWSk' - PD PR_Swap to Sink
      2. 5.3.2  'SWSr' - PD PR_Swap to Source
      3. 5.3.3  'SWDF' - PD DR_Swap to DFP
      4. 5.3.4  'SWUF' - PD DR_Swap to UFP
      5. 5.3.5  'GSkC' - PD Get Sink Capabilities
      6. 5.3.6  'GSrC' - PD Get Source Capabilities
      7. 5.3.7  'ESkC' - PD EPR Get Sink Capabilities
      8. 5.3.8  'ESrC' - PD EPR Get Source Capabilities
      9. 5.3.9  'GPPI' - PD Get Port Partner Information
      10. 5.3.10 'SSrC' - PD Send Source Capabilities
      11. 5.3.11 'MBRd' - Message Buffer Read
    4. 5.4 Patch Bundle Update Tasks
      1. 5.4.1 'PBMs' - Start Patch Burst Mode Download Sequence
      2. 5.4.2 'PBMc' - Patch Burst Mode Download Complete
      3. 5.4.3 'PBMe' - End Patch Burst Mode Download Sequence
      4. 5.4.4 'GO2P' - Go to Patch Mode
      5. 5.4.5 'FLrd' - Flash Memory Read
      6. 5.4.6 'FLad' - Flash Memory Write Start Address
      7. 5.4.7 'FLwd' - Flash Memory Write
      8. 5.4.8 'FLvy' - Flash Memory Verify
    5. 5.5 System Tasks
      1. 5.5.1 'DBfg' - Clear Dead Battery Flag
      2. 5.5.2 'I2Cr' - I2C read transaction
      3. 5.5.3 'I2Cw' - I2C write transaction
      4. 5.5.4 'GPsh' - set GPIO high
      5. 5.5.5 'GPsl' - set GPIO low
  8. 6User Reference
    1. 6.1 PD Controller Application Customization
    2. 6.2 Loading a Patch Bundle
    3. 6.3 AUTO_NEGOTIATE_SINK Register
      1. 6.3.1 AUTO_NEGOTIATE_SINK usage example #1
      2. 6.3.2 AUTO_NEGOTIATE_SINK usage example #2
      3. 6.3.3 AUTO_NEGOTIATE_SINK usage example #3
      4. 6.3.4 AUTO_NEGOTIATE_SINK usage example #4
    4. 6.4 IO_CONFIG Register
      1. 6.4.1 GPIO Events
  9. 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_Sink_Cap_Extended (control message)
  • Get_Status (Control message)
  • Get_Country_Codes (Control message)
  • Get_Country_Info (Data 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_Sink_Capabilities or 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 'GSkC' to send Get_Sink_Capabilities and 'GSrC' to send Get_Source_Capabilities messages.

This Task is defined to enable supporting any new Get message that can be defined by USB PD in the future.

Table 5-12 'GPPI' - Send a USB PD Get* Message
DescriptionThe 'GPPI' Task instructs PD Controller to issue a specific USB PDmessage to the Port Partner at the first opportunity while maintaining policyengine compliance.
INPUT DATAXBitNameDescription
15Reserved
14:13FrameType
00bSOP
01bSOP'
10bSOP''
11bReserved
12:8NumBytes
7Reserved
6:5MessageCategory
00bControl 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. For example, the Port Partner is a Sink and indicated (through previous Source or Sink Capabilities) it was not Dual-Role Power.
  • The PortPartner replies with a Reject or Not_Supported message.
  • The USB PD spec revision (PlugPartnerNegSpecRev or PortPartnerNegSpecRev in PD3_STATUS register (0x41) does not allow sending the requested 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 EffectsIf necessary, the PD controller can issue a VCONN_Swap in order to send the requested message to a Cable Plug.

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. The host can want to issue the 'ABRT' Task if the process takes too long. Some scenarios where this can happen are:
  • The PD controller is required to be the VCONN_Source in order to send any message on SOP or SOP'. The PD controller will continue trying to become the VCONN provider until it is successful.
  • 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.

The host must wait until CMDx reads as 0 or INT_EVENT1.CmdComplete is asserted before issuing the 'MBRd' 4CC Task to read the Rx Buffer after issuing 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.

 Example Sequence for 'GPPI' Task When Host
                    Uses INT_EVENT1Figure 5-1 Example Sequence for 'GPPI' Task When Host Uses INT_EVENT1
 Example Sequence for 'GPPI' Task When Host
                    Uses CMD1 PollingFigure 5-2 Example Sequence for 'GPPI' Task When Host Uses CMD1 Polling
 'GPPI' Interrupted by an Unknown
                    MessageFigure 5-3 'GPPI' Interrupted by an Unknown Message
 'GPPI' Interrupted by an Unknown Extended
                    MessageFigure 5-4 'GPPI' Interrupted by an Unknown Extended Message