USB PD DRP does not work

Rise · ‎2023-12-17

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 · ‎2023-12-18

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 · ‎2023-12-18

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:

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

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 · ‎2023-12-19

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