Skip to main content
L
Lvan .4
Visitor II
November 10, 2022
Solved

Why do I not receive a USBPD_NOTIFY_SRCCAP_SENT notification?

  • November 10, 2022
  • 3 replies
  • 1793 views

I am trying to set up a sourcing power delivery port on an STM32G0 system. I have set up switching of VBUS, and when I connect up a sinking device my system detects it, sets up VBUS and starts sending source capacity messages.

Log:

<Connect source to port 0>
USBPD_DPM_Notification - USBPD stack started
USBPD_DPM_UserCableDetection - Cable attached to port 0; role=sink
USBPD_DPM_Notification - USBPD stack started
USBPD_DPM_SetDataInfo - Reset sink PDO on port 0 (data=0)
USBPD_DPM_SetDataInfo - Received sink request of size 1 on port 0
USBPD_DPM_SetDataInfo - Received 5 Source PDOs on port 0
USBPD_DPM_SNK_EvaluateCapabilities - Selecting PDO offer 0
USBPD_DPM_Notification - Power state changed on port 0
USBPD_DPM_Notification - Request accepted on port 0
USBPD_DPM_Notification - Power state changed on port 0
USBPD_DPM_Notification - Explicit contract on port 0
USBPD_DPM_Notification - Sink ready on port 0
 
<Connect sink to port 1>
BSP_USBPD_PWR_VBUSOff on port 1
USBPD_DPM_Notification - USBPD stack started
USBPD_DPM_UserCableDetection - Cable attached to port 1; role=source
BSP_USBPD_PWR_VBUSOn on port 1
USBPD_DPM_Notification - USBPD stack started
USBPD_DPM_SetDataInfo - Reset sink PDO on port 1 (data=0)
USBPD_DPM_SetDataInfo - Received sink request of size 1 on port 1
USBPD_DPM_Notification - Power state changed on port 1
USBPD_DPM_GetDataInfo - get source PDO
USBPD_DPM_IsPowerReady - Power supply check on port 0 // << Port 1 passes on the PD contract of port 0, so checking port 0 is part of determining whether port 1 is able to source

Using a PD analyzer I can see that VBUS goes up and three source capabilities messages are sent, but that is where the process hangs. Nothing happens and I do not receive a USBPD_NOTIFY_SRCCAP_SENT notification, presumably because the source capabilities messages never get acknowledged by the sink device.

I can see that the USBPD_CAD_Task keeps running (removing cables also triggers new activity), and I do not see any error handling calls. Comparing my code to stm32 source port example code, there are no differences that I can find that would explain this behaviour.

It looks like something hangs in some state machine while sending SRC_CAP messages, but I have no clue where to start searching for where the process fails.

    This topic has been closed for replies.
    Best answer by Lvan .4

    Hi Nicolas,

    Yes, my issue is solved. I followed the steps in this example, but this skipped setting up a call to USBPD_DPM_TimerCounter. I also figured that all timing related things were taken care of because I set up a USBPD timebase in CubeMX and the Sink part of my USBPD stack was working fine.

    I later stumbled upon this function and noticed it had no calls at all, so I put it in a systick handler and that did the trick.

    Of course, right after the fact I did come across this in the FAQ section on that same wiki (But under a slightly different problem description 9.10 Why is the PD message not sent by the stack? which is why I glossed over this the first time I went through this FAQ.. I wás seeing PD messages..)

    Thanks for the follow-up!

    3 replies

    N
    Nicolas P.
    ST Employee
    November 14, 2022

    Hello @Lvan .4​ 

    Did you activate the trace tool that we provide ? It would help for debugging.

    See this link in our wiki : Tracer tool

    Because in the trace you shared we don't see the GoodCRC message, so we cannot be sure that your sink device got the messages.

    Once you have the UCPD monitor in place you could share your debug trace here, so we can help.

    N
    Nicolas P.
    ST Employee
    December 15, 2022

    Hello @Lvan .4​ 

    have you solved your issue ?

    Regards,

    Nicolas

    L
    Lvan .4AuthorAnswer
    Visitor II
    December 16, 2022

    Hi Nicolas,

    Yes, my issue is solved. I followed the steps in this example, but this skipped setting up a call to USBPD_DPM_TimerCounter. I also figured that all timing related things were taken care of because I set up a USBPD timebase in CubeMX and the Sink part of my USBPD stack was working fine.

    I later stumbled upon this function and noticed it had no calls at all, so I put it in a systick handler and that did the trick.

    Of course, right after the fact I did come across this in the FAQ section on that same wiki (But under a slightly different problem description 9.10 Why is the PD message not sent by the stack? which is why I glossed over this the first time I went through this FAQ.. I wás seeing PD messages..)

    Thanks for the follow-up!

    Terms & ConditionsAccessibility statement