Skip to main content
Explorer II
October 17, 2024
Question

USB-C Power Delivery Source Cable never detected

  • October 17, 2024
  • 4 replies
  • 2924 views

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

    This topic has been closed for replies.

    4 replies

    Technical Moderator
    October 17, 2024

    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);

    captatAuthor
    Explorer II
    October 18, 2024

    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?

    Technical Moderator
    October 18, 2024

    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. 

    FBL_0-1729245884443.png

    captatAuthor
    Explorer II
    October 21, 2024

    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!

    Technical Moderator
    October 21, 2024

    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.

    Technical Moderator
    October 28, 2024

    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.

    FBL_0-1730120494979.png

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

    FBL_2-1730121173716.png