STM32U585 USBPD Not Working

[cd3361]

I am currently using the STM32U585 MCU on a custom board and am trying to get the MCU to function as a DRP device in the USB-C PD protocol. Although currently I am just trying to get the device to work as a SNK (with DRP capability enabled). The project I am implementing this in is using ThreadX as the RTOS.

I have followed multiple tutorials for getting USB-C power delivery implemented on ST MCUs and have implemented the needed changes in the CubeMX .ioc file and have also made the necessary changes in the code listed in AN5418.

I have also referenced plenty of example projects including: DemoUCPD, USB-PD_Consumer_1port, USBPD_DRP_UX_DRD_HID, USBPD_SNK, and USBPD_SNK_UX_Device_HID_CDC_ACM.

One thing that is worth noting is our custom PCBs do not have the TCPP IC on our board, contrary to a lot of the examples. Also, a lot of examples also seem to use FreeRTOS, but the rest of our project has been using ThreadX, so didn't want to make the switch.

Here is what I have found so far, using this flow diagram as the expected sequence of events in a Sink Power negotiation:

-Device gets through initialization and reads the VBUS voltage correctly.

-When a USB-C cable is plugged in (USB-C to USB-C cable with USBPD capable power source) the program is able to enter the USBPD_DPM_SetDataInfo, but instead of entering with a USBPD_CORE_DataInfoType_TypeDef of USBPD_CORE_DATATYPE_RCV_SRC_PDO, it enters with USBPD_CORE_DATATYPE_RDO_POSITION and then with a subsequent call with USBPD_CORE_DATATYPE_RCV_REQ_PDO. It then repeats this a second time with nothing happening. This doesn't match the flow in the picture above.

-USBPD_DPM_SNK_EvaluateCapabilities is never called.

-I have used both the STM32 UCPD Monitor and a Cypress USB-PD monitor. All I see is that my device only ever sends zeroes back. I can see the USB-C power source sending the correct messages so I can confirm that the power source is working.

-Using a breakpoint in the code I can see that the code enters USBPD_PORT0_IRQHandler and correctly enters UCPD_SR_RXMSGEND when the USB-C cable is plugged in. I can also see a byte being received in my buffer, but can only see one byte at a time since that is the size of the UCPD RX register.

-I tried to look at the memory location where I would expect to see the full message received, but I only ever see zeroes (potentially a DMA issue?).

I have looked at multiple example projects and most of them seem to have the same file content between them. Since the SetDataInfo callback is being called with reasonable parameters and the IRQ handler is getting to RXMSGEND, I assume that we are possibly receiving data correctly, but I could be wrong.

I have tried just using the application in SNK mode rather than as a DRP, and I have gotten the same results.

Any help or hints would be greatly appreciated.

[cd3361]

@FBL 

Awhile back I was able to get the USBPD_DRP_UX_DRD_HID (uses ThreadX) example working with the STM32H573I-DK and this is what the sequence looked like:

Can see that after SRC sends its capabilities the SNK (dev kit) sends a GOODCRC. Whereas on my board it just sends 0x0 back (one tool called this a C_RSVD0 message and the other called it an Unknown_CONTROL_ID message).

Regardless if my board couldn't support the capability, shouldn't it follow the Source's capabilities with a GOODCRC message?

[FBL]

Hi @cd3361 

You could have your definition of SNK PDOs covering various voltages and power. At the end, whatever those PDOs, decision about which SRC PDO to choose to build the REQUEST message is a SNK decision.
Entry point of this selection/decision in ST provided examples is the USBPD_DPM_SNK_EvaluateCapabilities function. You might feel the need to update SNK PDO, in order to request the "right" SRC PDO, as current example implementation is looking for a "best match" between received SRC PDOs, and defined SNK PDOs. To learn more check this.

To conclude @cd3361 , the example provided should be working. Potentially, you have an in issue in your hardware, custom PCB, so your parts being used after reset blocks the hard reset message (which explains why source can't see it) ? ... Maybe the sink would like to send a hard reset. but if nothing is coded, no way the source can see the message.

[cd3361]

Hi @FBL 

As far as EvaluateCapabilities is concerned, my code never enters EvaluateCapabilities. So unless I'm missing some intermediate step, it doesn't seem like an incorrect PDO could cause this?

With regards to the hardware, the CC lines are connected directly to the dedicated MCU pins on the board. Is there an intermediate IC that is needed? From what I have found it doesn't sound like it is necessary for the CC lines.