USB-C Power Delivery Source Cable never detected

[captat]

I have a custom board with a STM32G431CBU3 connected to a TCPP02-M18 for a USB-C power delivery source solution. I follow the ST tutorials for setting up the USBPD and TCPP middlewares in STM32Cube IDE. I'm also able to get trace data out, which I've attached and pasted below. This is all the trace data I get out. Nothing happens when I plug in a USB-C PD sink into my custom board, the mcu never detects that a sink device is connected. 

I've looked at UM2552 and the "sequence for source Detection" section. It says that it tries to "detect the presence of Rd resistor" and will trigger the USBPD_DPM_CADCallback when the Rd resistor is detected, but I never see that happen. What criteria exactly is the mcu looking for to detect the presence of a Rd resistor that will trigger the USBPD_DPM_CADCallback function? Does it need to see a specific voltage at the CC1 and/or CC2 pins? Any ideas where I can go from here or anything else to check?

DEBUG 3003 1 -- BSP_USBPD_PWR_Init -- 0
DEBUG 3003 1 -- TCPP02 detected 1
DEBUG 3003 1 -- BSP_USBPD_PWR_SetRole : SRC -- 2
DEBUG 3003 1 -- BSP_USBPD_PWR_SetPowerMode -- 3
DEBUG 3004 1 -- Low Power -- 4
CAD 3004 1 USBPD_CAD_STATE_DETACHED 5

[FBL]

Hi @captat 

> What criteria exactly is the mcu looking for to detect the presence of a Rd resistor that will trigger the USBPD_DPM_CADCallback function? Does it need to see a specific voltage at the CC1 and/or CC2 pins? Any ideas where I can go from here or anything else to check?

Here is a wiki to develop a SRC project with custom board 

Check your CC line level , If the CC lines do not change, check that this TCPP is pass through!

If you have an issue on the CC2 for STM32G4, verify that in usbpd_cad_hw_if.c you put the CC2 line to the analog mode. You should have: LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_4, LL_GPIO_MODE_ANALOG);

[captat]

Hi @FBL ,

Thank you for the tips. I checked that the pin mode was set correctly for CC1 and CC2 specifically, both set correctly to analog. I also checked the CC line voltages. With nothing plugged in, the CC lines are right around 3.0V. When I plug in a sink device with a USB-C cable, one line drops to about 900mV, and the other to about 0V, depending on the orientation I plug in the cable. I checked the CC voltages at the mcu pins as well and they were the same, so it looks like the voltage is passing through the TCPP chip fine. 

Is there anything else I can check? It seems like the CC lines are doing what they are supposed to, the CAD task just isn't recognizing when the cable is plugged in. Is there a way to trigger the USBPD_DPM_CADCallback manually?

[FBL]

Weird! Could you share your schematics and your software? @captat 

When acting as a source, G4 must present an Rp resistor then it must detect Rd resistor and wait for debounce! 

CC1 should be connected to Rp first when acting as a SRC. 

[captat]

Pictured below is the relevant parts of my schematic, I based it heavily off then X-NUCLEO-SRC1M1 board that I have been developing with. I am not sure what parts of my project might be useful, so an entire archive of the STM32Cube IDE project is attached. 

I noticed something very interesting though. I manually check the TYPECEVT1 and TYPECEVT2 interrupt flags in the UCPD_SR register in my code before the RTOS starts, and they seem to be working setting as intended when I plug in and unplug a USB cable. I can even clear them and retrigger them by plugging in the cable again. 

BUT, they never seem to actually trigger an interrupt. It looks like they are supposed to trigger the PORTx_IRQHandler function located in the usbpd_hw_if_it.c file, but that never seems to happen either before or after the RTOS starts.

In fact, after the MX_USBPD_Init() function executes in the main function, I can't seem to get ANY interrupts to trigger. I tried triggering a basic gpio interrupt to trigger, but even that doesn't happen. I tried re-enabling interrupts with  __enable_irq() but that isn't doing anything. 

Any ideas why interrupts are not triggering after the MX_USBPD_Init() function call?

[captat]

So I did a bit more digging into the RTOS code, and I found a few lines if I comment out, I am actually able to successfully negotiate a PD contract with a sink device.

In the heap_4.c file, in the pvPortMalloc definition, I need to comment out the vTaskSuspendAll() and the xTaskResumeAll() function calls.

In the port.c file, in the vPortValidateInterruptPriority definition, I need to comment out the configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ) function call.

I don't really know why these functions seem to disable interrupts, it just took basically a ton of trial and error digging down the function calls to find where it was occurring and I didn't look any further. I don't know what the potential future ramifications of removing these function calls might be, but I am technically able to establish a PD contract if I remove them, which is good I guess!

[FBL]

Hi @captat 

Thank you for the updates and digging further. I assume you are facing an issue with task scheduling. I guess PWR_TCPP0203_ITConfigInit() function is missing in your implementation which configures the interrupt settings for the TCPP0203 component. Also, TCPP0203_PORT0_FLG_EXTI_IRQHANDLER() PWR_TCPP0203_GPIOConfigInit() which configures the GPIO settings for the TCPP0203. 

By ensuring these configurations, you can avoid this issue related to interrupt required for handling USB PD events and detect presence of Sink.

[FBL]

Hi @captat 

I figured out something that could be interesting in your board. R9 protects the TCPP02-M18
from overcurrent on the VBUS. When this voltage is higher than 0.042 V, the overcurrent protection turns on and
opens the provider path. So having 2512.7mOhm as OCP is too much. The recommended value is 7mOhm.

TVS ESDA25P35-1U1M D1 and C13 are missing as well