Skip to main content
Associate II
April 8, 2026
Solved

Adapted DRP1M1 Reference Design faults on Writing to UCPD controller

  • April 8, 2026
  • 1 reply
  • 112 views

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.

Best answer by JoeMck

I figured it out. The kernel clock (HSI) wasn't being turned on. 

1 reply

JoeMckAuthorBest answer
Associate II
April 8, 2026

I figured it out. The kernel clock (HSI) wasn't being turned on.