USB PD DRP does not work

[Rise]

Dear All,

I'm trying to integrate USB PD DRP into my code.

The DRP does not seems to work. I traced the port interrupts down to the PORTx_IRQHandler and here are the results (USB_PD_Int = Status Register, the time is in ms from the start of the FW):

Time   USB_PD_Int
3713   0x1c0cc000 - change in CC1/CC2
15194 0x000c0200 - Rx ordered set (4 K-codes) detection - SOP
15195 0x000c1000 - Rx message received - charger sent SRC Capabilities (valid content)
15196 0x0c0c0004 - Message transmission completed - WRONG GoodCRC (with wrong MessageID)
15224 0x040c0400 - Rx Hard Reset receipt detection
16930 0x0c0c0020 - Hard Reset message sent
17982 0x0c0c0020 - Hard Reset message sent
19699 0x0c0c0020 - Hard Reset message sent

The GoodCRC message, which my MCU sends (originating from PRL_Received() function from within USBPDCORE_PD3_FULL_CM0PLUS_wc32.a library), contains wrong MessageID, which does not correspond to the MessageID received from the charger. How can I debug this? Is it possible to get library sources (I'm willing to sign an NDA if needed).

Thanks a lot and Best regards,

Boris.

[Guenael Cadier]

Dear @Rise 
Could you record a trace of your use case using method as described here ?
If shareable, please feel free to provide also your project, just in case we could investigate and debug it on our side ?
Regards

PS : ST USBPD Core stack is provided as library, and is not available in source code.

 

[Rise]

Dear Guenael,

I work with my own PCB with relatively complicated USB connection, so I'm not sure that You will be able to replicate FW behavior without my hardware. Anyway, I can provide You the project if You would like but please give me the private place to upload since this is an IP of my customer. I don't use ST tracing and I'm not sure how much time it may take me to add it. Please let me know which information is missing, I will try to provide it. At least now I can provide You with real messages I caught:

From my charger (Samsung PD, 5V/3A, 9V/2.7A) I've got the following:

0x43A1 = 0b 0 100 001 1 10 1 00001
| | | | | | |
| | | | | | Message Type=Source Capabilities
| | | | | Data Role=DFP
| | | | Spec Rev=3.0
| | | Power Role=SRC
| | Message ID - counter=1st message
| 4 data obj.
0

0A01912C = 0b 00 0 0 1 0 1 0 0 0 00 0001100100 0100101100
| | | | | | | | | | | |
| | | | | | | | | | | Current in 10mA units=300 -> 3000mA
| | | | | | | | | | Voltage in 50mV units=100 -> 5000mV
| | | | | | | | | Peak current=00 -> Peak is equal to output current (3000mA)
| | | | | | | | Reserved=0
| | | | | | | EPR Mode Capable=0
| | | | | | Unchunked Extended Messages Supported=0
| | | | | Dual-Role Data=1 -> Capable of Dual-Role operation
| | | | USB Communications Capable=0
| | | Unconstrained Power=1 -> AC power is available
| | USB Suspend Supported=0
| Dual-Role Power=0 -> SRC only
Fixed supply

0002D115 = 0b 00 0 0 0 0 0 0 0 0 00 0010110100 0100010101
| | | | | | | | | | | |
| | | | | | | | | | | Current in 10mA units=277 -> 2770mA
| | | | | | | | | | Voltage in 50mV units=180 -> 9000mV

C876213C = 0b 11 00 1 00 00111011 0 00100001 0 0111100
| | | | | | | | |
| | | | | | | | Maximum Current in 50mA units=60 -> 3000mA
| | | | | | | Reserved=0
| | | | | | Minimum Voltage in 1000mV units=33 -> 3300mV
| | | | | Reserved=0
| | | | Maximum Voltage in 1000mV units=59 -> 5900mV
| | | Reserved=00
| | PPS Power Limited (may accept PDO with lower current within the power limit)
| SPR Programmable Power Supply
Augmented Power Data Object (APDO)

C8DC2137 = 0b 11 00 1 00 01101110 0 00100001 0 0110111
| | | | | | | | |
| | | | | | | | Maximum Current in 50mA units=55 -> 2750mA
| | | | | | | Reserved=0
| | | | | | Minimum Voltage in 1000mV units=33 -> 3300mV
| | | | | Reserved=0
| | | | Maximum Voltage in 1000mV units=110 -> 11000mV
| | | Reserved=00
| | PPS Power Limited (may accept PDO with lower current within the power limit)
| SPR Programmable Power Supply
Augmented Power Data Object (APDO)

The GoodCRC message ST library tries to send is this:
00000E41 = 0b 0 000 111 0 01 0 00001 - GoodCRC?

As far as I understand the message ID field that supposed to be there should contain 001 as a receipt for Source Capabilities message #001 sent by charger. Instead I see there 111. Mybe there are other reasons why charger resets itself later? 

 

[Guenael Cadier]

Hello @Rise 

Following decoding of the message header values you provided, SRC capabilities message decoding is indeed showing use of MsgID value  = 1, and GoodCRC reply is shown using 7 which is not expected indeed.
However, as MsgID of SRC capabilities is 1, and as it is expected to start from 0 value, this means that there is prior to this exchange, a message with MsgID 0 that has been successfully acknowledged.
Could you confirm this ?
It is hard to investigate without our internal trace system, so please check if you could output our trace using a UART for example ... No real clue on what is happening. As this behavior looks really weird, one generic idea that might be worth a try, would be to increase your application stack size, just to check if it could be linked to a memory corruption due to a stack overflow ?
Regards