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

[AOhir.1603]

Hi Yohann,

I've been implementing solution for TEST3 case and we are getting PE_STATE_HARD_RESET 500ms after PE_SNK_WAIT_FOR_CAPABILITIES.

I've added my timer and it is triggering correctly but it does not execute my operation well.

Question:

1. What can we expect when we see PE_STATE_HARD_RESET? Currently I don't see anything after PE_STATE_HARD_RESET and the only way to recover seems to be repowering the unit. From the UM2552.pdf section 4.2.4 it looks like I should be getting NOTIFY_POWER_STATE_CHANGE and NOTIFY_HARDRESET_TX but none of that is seen on my end. When I run in debug mode, I seem to find it in HardFault_Handler.
2. What is a Hard Reset in USBPD form? Is it resetting just the USB PD coms and states? Or does it involve actual reset on TCPM side as well ?

Thanks,

AOF

[Yohann M.]

Hi AOF,

When SRC port partner is not PD capable, reception of hard reset will not have impacts. On Sink side, we just restart the state machine and wait for a new SRC capa. After 3 trials, we stop the PD stack.

You should NOT enter in hardfault_handler :-(. Could you investigate further this problem?

Regards,

Yohann

[AOhir.1603]

Hi Yohann,

I have investigated this and found that PE tasks were having a stack overflow.

I've added vApplicationStackOverflowHook to find this error.

So now I've increased the stack size from 150 to 300 and it is behaving the way you described! Yeay!

I'm now seeing PE_DISABLED_STATE but how do I proceed from here? Where in the usbpd_dpm_user code can I catch this state and start charging the battery?

Thanks,

Ayaka

[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

[Yohann M.]

Hi Ayaka

As I told you in a previous comment, "Unfortunately, in the release DV2.1.0, this notification does not exist. It is present in our latest stack release done for STM32G0 (DV1.3.0 for instance).

In the current FW you have, I advise you to start a timer on DPM side when you detect a CAD detection and after 1500ms, you could start drawing minimum USB current."

For the time being, this is the solution I will suggest you to use.

Regards,

Yohann

[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

[Yohann M.]

Hi Ayaka,

For your information, we pushed under github an update of the XCUBE-USB-PD package:

* https://github.com/STMicroelectronics/x-cube-usb-pd

Could you please try to align your FW on this package to get the up-to-date modifications done on our stack?

Regards,

Yohann

[AOhir.1603]

Hi Yohann,

I've cloned the git repo and have tried to run the example application on the on-semi development board but I am having some issues with the application code.

I am using STM32CubeIDE v1.3.0 that I downloaded yesterday.

Compiler used is GNU Tools for STM32 7-2018-q2-update

Using st-link v2; FW v2.J36.s7

The compiler happily compiles without error but the image it creates is very odd.

I first could not debug the project so I went to st-link utility to just load the image.

When I loaded the image, the values seem weird - address range for flash is not correct and usually you see similar values for reset vector but for this image, it was well off.

I'm attaching the binary file that I compiled for your reference.

If you could, could you build the project on system workbench?

The last application example for FUSB307 builds and can debug succesfully in the system workbench.

Thanks,

AOF

[AOhir.1603]

Hi Yohann,

Thank you for the update on the library.

We wanted to try the example application (EVAL_FUSB307_DRP) on the on-semi FUSB307 development board but I cannot load the image onto the board.

I am using STM32CubeIDE v1.3.0, using compiler GNU Tools for STM32 7-2018-q2-update.

The IDE happily compiles without error but when I tried to debug it, it kept failing.

I then tried to just load the image created using ST-Link utility but when the image was loaded, it seems very off.

I've attached the image here for your reference.

Could you please make sure you can build with stm32CubeIDE and debug it on the on-semi board?

Either that, if you could create a project for system workbench, that would be useful.

Thanks,

AOF