USB PD library gets stuck in loop waiting for VBus to be 0V when a USB-C charger plugged

[AOhir.1603]

Hi there,

We have a custom board with STM32F030CC and PTN5110 chip as the TCPC. We are using the x-cube-usb-pd library with config USBPD_TCPM_LIB_PD3_CONFIG_1.

Initially, DRP role is selected. When we plug in a standard USB-C charger (5V 3A output) to the port, TCPC reports to present Rd role. That is, in tcpc_driver->get_cc(), it returns CC_STATUS as 0x13.

But the firmware gets stuck in USBPD_DPM_IsPowerReady(), as it waits for the VBus to be 0V but the charger is presenting 5V so it gets stuck in a loop calling USBPD_DPM_IsPowerReady() (USBPD_TCPM_VBUS_IsVsafe0V() is returning USBPD_ERROR).

The firmware currently crashes after it calls USBPD_DPM_IsPowerReady() multiple times..

Could someone please help me understand why when USBPD_DPM_IsPowerReady() is called, it is waiting for VBus to be 0V in this situation? I know that VBus is actually 5V and I thought it should check to make sure VBus is 5V but library is doing the opposite.

Is there a setting I need to configure (DPM_Setting, PDO setting etc)?

Any idea would be appreciated.

Thanks,

AOF

[Yohann M.]

Hello

Could you please attach in PD trace generated with CubeMonitor?

"For your information, we have a way to trace messages exchanged between our solution and the port partner thanks to trace mechanism.

Please have a look to the following thread: https://community.st.com/s/question/0D50X0000BdfSu2SQE/how-to-use-debug-trace-trace-

I advice you to switch to 'Consumer_RTOS' application. You could enable in this project the compilation switch _TRACE.

Then in using Cubemonitor-UCPD, you will be able to check what happens exactly.

The binary log (.cpd file) can be retrieved locally in your hard disk under:

C:\Users\<login>\AppData\Local\Temp\STM32CubeMonitor-UCPD\Acquisition

You could attach directly this file for analysis."

Regards,

Yohann

[AOhir.1603]

Hi Yohann,

Thanks for your answer.

Just to clarify, I am using the USBPD_TCPM_LIB_PD3_CONFIG_1 configuration.

Could I still use the 'Consumer_RTOS' example by just changing the defined symbol to what I require it to be?

I will try and get the trace using CubeMonitor-UCPD from the application I have set up already as well.

Thanks,

AOF

[Yohann M.]

Hi AOF,

I advise you to start from EVAL_FUSB307_DRP project and disable _DRP switch (keep only _SNK switch) and then compare to 'Consumer_RTOS' project to fix different errors, mainly:

• copy 'usbpd_pdo_defs_Snk_1Port.h' file in this application (use to define SNK PDO)
• Few updates in 'usbpd_dpm_user.c' and 'usbpd_pwr_if.c' linked to Souce PDO and VBUS management

Please find updated files.

Regards,

Yohann

[Yohann M.]

'usbpd_dpm_user.c' and 'usbpd_pwr_if.c'  in sink only

[AOhir.1603]

Hi Yohann,

I've found that the problem was the PE task having stack overflow so I've now increased the stack size from 150 to 300 in usbpd_dpm_core.c.

I found this out by adding the hook for stack overflow (vApplicationStackOverflowHook).

Now my firmware is doing what you said - restarts the state machine 3 times and then stops PD stack (PE_DISABLED_STATE)! Yeay!

But now what do I do? How do I catch this in the user code? Is there a callback I can use in usbpd_dpm_user.c to catch this scenario?

Thanks,

Ayaka

[AOhir.1603]

Hi Yohann,

Thanks for clarifying the suggested solution before. I've implemented the solution with a custom timer and seems to work well.

Now, I've moved on to testing with a smart USBPD com capable charger and I have a question.

Using the same code and same charger I get different behaviour:

1. It successfully reaches USBPD_NOTIFY_POWER_EXPLICIT_CONTRACT and can start charging my battery
2. It seems to go through the PDO negotiation but does not reach USBPD_NOTIFY_POWER_EXPLICIT_CONTRACT. For some reason it does a Hardreset and ends up PE_DISABLED_STATE.

I've attached logs for these two cases (1. PDCharger_Working.cpd and 2. PDCharger_Hardreset.cpd).

Could you tell me why it ends up in different cases and how I could work around or fix it so it always ends up in explicit contract?

FYI I am using Nintendo switch charger to test.

Thanks,

AOF

[Yohann M.]

Hello Ayaka,

we may have on this release a system issue which leads to the fact that stack is not able to handle 2 messages coming too quickly (not able to change PE state machine after sending request message and accept message) We fixed similar issues in our latest baseline (Enable/disable RX interfaces added between the TCPM and TCPC). it allows to be sure that TCPM had the time to change its internal state machines before handle a new message..

I expect that your problem will be fixed in our next release (do our best to deliver it ASAP).

Regards,

Yohann