STM32U5 - USB CDC UART not working: USBPD_DPM_CADCallback(..) is not calling

[Riscy]

I have build the project with Nucleo_U5A55ZJ-Q with 1.4.0 and 6.2.0 library from the start, following the example code (working) with IOC setup (USBPD and USBX).  After fixing the CSRST issue earlier with missing __HAL_RCC_SYSCFG_CLK_ENABLE() but I note the demo code do not use this command.

The code is running, but there is no COM port (the demo code (2021) did work with COM3). I found the  USBPD_DPM_CADCallback(..) is not calling.

Below is code found in uspd_dpm_core.c where the DEF_TASK_FUNCTION(USBPD_CAD_Task) is working (via breakpoint), which suggests the interrupt is responding okay. 

I have spent 5 hours trying to figure out the difference between the generated code (2024) and the demo code (2021). I'm open to investigating why USBPD_DPM_CADCallback(..) is not calling. I attached ioc file. 

DEF_TASK_FUNCTION(USBPD_CAD_Task)

{

uint32_t _timing;

#ifdef _LOW_POWER

UTIL_LPM_SetOffMode(LPM_CAD, UTIL_LPM_DISABLE);

#endif /* _LOW_POWER */

for (;;)

{

_timing = USBPD_CAD_Process();

OS_GETMESSAGE_QUEUE(CADQueueId, _timing);

}

}

/**

* @brief CallBack reporting events on a specified port from CAD layer.

* @PAram PortNum The handle of the port

* @PAram State CAD state

* @PAram Cc The Communication Channel for the USBPD communication

* @retval None

*/

void USBPD_DPM_CADCallback(uint8_t PortNum, USBPD_CAD_EVENT State, CCxPin_TypeDef Cc)

{

[Riscy]

Thank you; I found it: USBPDCORE_NOPD_CM33_wc32.a but it is not readable with Notepad++ or CubeIDE. I tried Segger Ozone, but it showed garbage.

I found there Objdump, which is a disassembler, but this works for Linux, which I lacks.

Any suggestion on how to view the .a or .lib file with disassembly via Windows so I can review it without running it or debugging it?

Based on the text message, it appears there is no comment about it. do you have the original disassembly version? 

[Riscy]

Any progress or solution for this query, thanks.

[FBL]

Hi @Riscy 

The source code is not open source. To learn more about mechanisms used to interact with the stack, check UM2552 section 3.4.3.

[ASimo.3]

I found my way here while having similar problems with STM32U575ZI Nucleo.  I learn some things so I wanted to post it in case it helps someone else.    I have a custom board that has the same USB-C HW setup I copied directly from the Nucleo Altium files.  I could not get the USB to work on either my custom board or the Nucleo if I started my own project from scratch using STM32CubeMX (R6.11.0 and FW_U5V1.50).  I had the same problem USBPD_DPM_CADCallback(..) would not fire.   It did however work fine if I used the demo code (UX_Device_CDC_ACM) - this was true on either board... even though my custom board has the VI package not the ZI.  I wasted a ton of time tracking down the solution and here is what worked for me.  For some reason just adding the BSP files from the demo project to mine made the callback fire!!!  You don't have to include or call anything they just need to be there.

You may need to rename stm32u5xx_nucleo_conf_template.h" to stm32u5xx_nucleo_conf.h"

After finding that worked.  I found that the functions from this library are called in usbpd_cad_hw_if.c however even if they are not in the project it doesn't generate any errors. Also, they are not included anywhere.  SO, I went further and pulled out only the stuff from the BSP that made it work and added it to the project.  I was then able to remove the BSP folder and it still works!!!.   For some reason just having this stuff in your project makes the callback fire.  See attached files with just the stuff you need from the BSP library.  

If there is a better place for me to put this info let me know!

[Wakka]

Thank you so much. Like you - I've spend WAY too much time on tracking this down. As you - I tried to create a working USBX application on NUCLEO-U575ZI-Q with not much luck. I already had given up on STM32U5 until I saw this post. Now I'll give it another try.

The technical reason for the problem is that the callbacks in usbpd_pwr_user.c (generated by STM32CubeMX) are declared __weak and is therefore overridden by the same callbacks declared in stm32u5xx_nucleo_usbpd_pwr.c (without the __weak keyword).

Again thanks!