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.]

Dear AOF,

System workbench is no more supported.

Anyway, I found that the issue is linked to a wrong LD file used by STM32CubeIDE. I just renamed the file 'STM32F072RBTx_FLASH.ld' to 'STM32F072RBTX_FLASH.ld'.

You should be able to generate correctly binary file.

Let me know your status.

Regards,

Yohann

Note: Please find my binary file for reference. Github also updated accordingly.

[AOhir.1603]

Hi Yohann,

That was it. I can now run the example application on the on-semi development board.

Good to know that System workbench is no longer supported.

One thing to note, in usbpd_dpm_conf.h, you have

#if defined(_GUI_INTERFACE)
#include "gui_api.h"
#include "usbpd_gui_memmap.h"
#endif /* _GUI_INTERFACE */

but if you undefine the _GUI_INTERFACE, you will get a compiler error so you can get rid of the #if defined(_GUI_INTERFACE).

I now have ported it to my board and was testing and have one odd issue.

I just want to use _TRACE and not _GUI_INTERFACE but for some reason if I disable _GUI_INTERFACE, the application goes into hardfault as soon as USBPD_DPM_Run() is called. But if I have _GUI_INTERFACE enabled, I dont have hardfault error and can run the application as expected.

Would you have any clue to why this could be? I did not see this behaviour on the on-semi board so it's specific to my application but my application does not differ too much - I have 3 additional tasks running but they are running slowly and not very intense tasks.

I am creating my tasks just before USBPD_DPM_Run() is called.

Let me know your thoughts on this.

I will continue to test the performance of new library with _GUI_INTERFACE enabled for now.

Thanks,

AOF

[Yohann M.]

Dear AOF,

I fixed the problem of deactivation of GUI in github (https://github.com/STMicroelectronics/x-cube-usb-pd/commit/2541ff3ca9fd1eb2bded7f8395ce8f9a9682f1b4)

For your issue, it may be linked to the FreeRTOS heap size? or problem with stack size used by the tasks? You could try to increase these settings (configTOTAL_HEAP_SIZE in FreeRtos_config.h for instance)

Regards,

Yohann

[AOhir.1603]

Hi Yohann,

I still haven't narrowed down why I need to have _GUI_INTERFACE enabled for the library to work properly but I will update you on that once I figure that out.

For now, we have a separate issue.

Currently we have setup a port to be DRP and testing sourcing a higher voltage PDO (9V 0.9A) and for some reason the library seems to fail outputting that.

The test device we have is a cypress CY4533 and it is requesting 9V 0.9A and we get the explicit contract but when we start outputting the power, the library seems to stop or fail. I've attached a trace log and our PDO file.

Could you tell us why this could be happening?

We tried to validate this with the on-semi dev board as well but it doesn't seem to provide 9V even if it reaches explicit contract with PDO position of 2. It'll be good to test this on the example project and validate it.

Thanks,

AOF

[Yohann M.]

Dear AOF,

I tested in my side. Actually, default configuration on EVAL-FUSB board does not allow to increase VBUS voltage.

it is possible in using external 12V on 12V connector. In this case, you have to enable correctly the PIN SRC_HV of FUSB307 (JP4 need to be changed as well).

In the current application you have, we did not modify the HW_IF_PWR_SetVoltage function (usbpd_tcpci.c file). To change the current voltage, you have to implement your own way to change the voltage on your board.

Your trace shows a hard reset sent by port partner. It requested 9V as only 5V is turn on, I imagine that Cypress checks it and sends a hard reset as requested VBUS value is not set.

By the way, this communication thread becomes a little bit longer. Can you close it and open another thread discussion?

Thanks for your comprehension.

Yohann

[AOhir.1603]

Hi Yohann,

I will try and change the code for the on-semi dev board and test sourcing 12V.

I've also created a separate thread as you suggested (it is getting too long!) and it's here: https://community.st.com/s/question/0D53W000000YQQiSAO/usb-pd-library-cant-source-higher-than-5v

Thanks for your support as always.

AOF