2026-04-08 6:56 AM
I've adapted the NUCLEO DRP1M1 reference design to build and compile for our Custom STM32U5A9 board, and when I run it, iit gets through these relevant pieces:
MX_GPDMA1_Init();
MX_UCPD1_Init();
MX_TCPP_Init();
But then in
MX_USBPD_Init() is seems to hang in the Call to:
USBPD_CAD_Init() which is part of the compiled STM_USBPD_Library.
Running a debugger and working my way backup the call stack, it appears that the library calls CAD_Init()
which ultimately calls
USBPDM1_AssertRd(PortNum)
where the debugger falls apart. AssertRd has at the beginning the 2 below calls
LL_UCPD_TypeCDetectionCC2Disable(Ports[PortNum].husbpd);
LL_UCPD_TypeCDetectionCC1Disable(Ports[PortNum].husbpd);
LL_UCPD_TypeCDetectionCC2Disable(Ports[PortNum].husbpd); <- appears to work fine.
LL_UCPD_TypeCDetectionCC1Disable(Ports[PortNum].husbpd); <- stops functioning.
husbpd points the appropriate address for the UCPD controller.
I've set a breakpoint here, and manually set CC2TDIS and is is fine, and then when I manually set CC1TDIS
it stops functioning, the debugger starts spewing "WARNING: Failed to read memory @ address 0x4000DCxxx
"
I am certain that there are (many?) issues in what I've adapted, but I'm looking for leads as to why writes
to the controller could be causing this condition. I backed out from triggering on reads/writes from the TCCP03-M20 chip.
I haven't looked too much at either the ADCs nor the DMAs.
I looked through UM2552 and didn't see too much about the actually controller.
Solved! Go to Solution.
2026-04-08 12:21 PM
I figured it out. The kernel clock (HSI) wasn't being turned on.
2026-04-08 12:21 PM
I figured it out. The kernel clock (HSI) wasn't being turned on.