cancel
Showing results for 
Search instead for 
Did you mean: 

Adapted DRP1M1 Reference Design faults on Writing to UCPD controller

JoeMck
Associate II

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.

1 ACCEPTED SOLUTION

Accepted Solutions
JoeMck
Associate II

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

View solution in original post

1 REPLY 1
JoeMck
Associate II

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