USB PD sink with TCPP03-M20 and STM32G0B1 is failing to set up PDO contract

[chris_O]

I want to implement a USBPD sink application with a 9V PDO and I am struggeling to set up a PD-contract with a source. I am using following components:

• STM32G0B1 MCU

• TCPP03-M20 PD controller

• My project is based on this example: https://github.com/STMicroelectronics/x-cube-tcpp/tree/main/Projects/NUCLEO-G071RB/Applications/USB_PD/DRP1M1_DRP

• X-Cube-TCPP v4.1.0

 

When I attach a PD-source, the DPM_Params[_port].PE_IsConnected variable is successfully set.

After that I get in USBPD_DPM_Notification a USBPD_NOTIFY_POWER_STATE_CHANGE event and afterwards a USBPD_NOTIFY_HARDRESET_TX event.

I also notice that I do not receive a message within PORTx_IRQHandler, as I do not jump into

if (UCPD_SR_RXMSGEND == (_interrupt & UCPD_SR_RXMSGEND))

…

Do you have any tips for me where I can start looking for my missing piece? Did i initialize something wrong?

[loveforcircuits]

Your sink connects but receives no PD messages. The stack then triggers a Hard Reset. This usually means RX is not working. Check TCPP03 sink configuration and CC pull-downs. Verify UCPD RX interrupts are enabled.
Confirm NVIC settings for the UCPD IRQ. Inspect UCPD IMR for RXMSGENDIE enable. Probe CC lines for incoming PD traffic. Ensure your 9 V PDO is correctly defined. Enable verbose stack debug for deeper insight.

[chris_O]

Thanks for your fast reply!

 

What do you mean with Check CC pull-downs? Shouldn t this be handled by TCPP03-chip and stack?

 

My UCPD RX interrupts are enabled and I compared my NVIC-settings with those from the example project, that seems fine.

I added temporary some trace-messages in PORTx_IRQHandler and I recognised I get some rx interrupts, it looks something like this:

….
UCPD_SR_RXMSGEND
RX OK
UCPD_SR_TXMSGSEN
UCPD_SR_TXMSGSEN
UCPD_SR_RXORDDET
UCPD_SR_RXMSGEND
RX OK
UCPD_SR_TXMSGSEN
UCPD_SR_RXORDDET
UCPD_SR_RXOV
UCPD_SR_RXMSGEND
UCPD_SR_RXERR

…

 

So it seems like my communication is working but I get some kind of overflow/error. Do you have any hints about this?


My PDO is not the problem. If I use some standard 5V-PDO from your examples the PD-communication still breaks.

 

[loveforcircuits]

I meant to say verify that the TCPP03 is actually configured into sink mode, so that it enables its internal Rd.

Since you now clearly receive traffic, CC wiring and pull-downs are fine. That is no longer the issue.

Inside your PORTx_IRQHandler, do you call:

USBPD_PORT0_IRQHandler(0);

or equivalent stack handler immediately?

If you added trace prints before the stack reads RXDR, that alone can cause overflow.

printf inside UCPD ISR is extremely dangerous.Remove all debug prints inside the UCPD ISR.
Make RXDR  read immediately after RXMSGEND. Set UCPD interrupt priority to highest level.
Check  the system clock. It should run at 64 MHz. Avoid long processing inside interrupt handlers.
Confirm RX flags are cleared correctly. Test again without debugger interference.

[FBL]

Hi @chris_O 

First, you may also find this step by step guide useful.  I recommend checking the hardware configuration of the X‑NUCLEO‑DRP1M1 in UM2891 for comparison with your design. 

To understand exactly where the PD negotiation fails, could you share a .cpd trace covering the period from plugging in the connector up to the Hard Reset?

In parallel, I would suggest trying to reproduce the behavior using the unmodified DRP1M1_DRP example, and then ensuring that your own hardware setup and configuration are aligned.

It looks like the PD contract issue might be related to message timing or interrupt configuration double-checking the UCPD interrupt setup and sequence of PD stack initialization can help. For projects where smooth setup and reliable performance matter, tools like Bn56 game download apk show how straightforward things can be.

[chris_O]

I was able to get one of the example projects with a Nucleo board with STM32G071 + TCPP03-20 board running.

In my project I am using a STM32G0B1, the example of this MCU in GitHub was not compiling out of the box, as it is missing a .project-file.

I also tried to create a custom project like https://wiki.st.com/stm32mcu/wiki/STM32StepByStep:Getting_started_with_USB-Power_Delivery_Dual_Role#Project_with_a_custom_board, this had some compile issues and after resolving them it did not even set DPM_Params[0].PE_IsConnected. So unfortunately this did not help.

 

About my hardware:
There are minimal differences in my hardware: the USBPD_PWR_ISENSE_RS is 10 instead of 7 mOhm. I just edited the #define. Apart from that it is basically the same as in the DRP1M1_DRP board.

 

About the trace:

I did not use all the traces with the TRACE-makro but some of them incl. some custom traces, as I was not able to connect with STM32CubeMonitor-UCPD. I added some of the logs (traces_usbpd.txt), maybe they are helpful . I can try to fix the init of the _TRACE-functions, if you think this helps.

Of course I deleted my trace-functions afterwards from UCPD ISR.

 

I also set UCPD interrupt priority to highest level, this did also not resolve the issue. The systemclock runs at 64 MHz, I tried both external and internal clock source.

 

Some thoughts from my side:

Is FreeRTOS CMSIS_V1 necessary or should _V2 also work?
I recognised that on rare times, the 9V-contract seems working. At least I could measure the 9V with a voltmeter, I had no debug-traces. That like a general timing problem. Do you have any hints about that?


I appreciate your help, thanks again!

[chris_O]

I fixed it finally. My last issue was hardware-related: my R1 / R2 bridge for Vsense was configured for VBUS max. = 6V and triggered an error via FLGN signal. I changed it to  VBUS max. = 10V and now it works smoothly.