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)

{

[FBL]

Hello @Riscy 

Are you sure about UX_DEVICE_APP_MEM_POOL_SIZE? It should not exceed total size of available memory. Also have you tried the example from cube firmware without changes in the config and HW setup?

[Riscy]

I had to reduce the UX_Slave_Request_Data_memory to 512 from 2048 to avoid crashing, even though I increased the UX Device mempool size to 32K in an attempt to stop crashing when using 2048, which did not resolve. The demo code uses 16K and 512. 

In the code: 

#define USE_STATIC_ALLOCATION 1

 

#define TX_APP_MEM_POOL_SIZE 1024

 

#define UX_DEVICE_APP_MEM_POOL_SIZE 32768

 

#define USBPD_DEVICE_APP_MEM_POOL_SIZE 5000

I checked the byte pool memory, and it reported no error. I'm familiar with Azure ThreadX. 

PS: I have attached the IOC file from the previous comment. 

 

 

[Riscy]

The above is the working demo code (2021) with a breakpoint to check USBPD_CAD_Process(); I found no source code for this function. The callback is working fine.

Below is the issue code (2024) with the same breakpoint as above; the callback is implemented but not run. I don't know what is happening in USBPD_CAD_Process() or why it is not calling a callback. The callback was implemented by the init code (from CubeMX), and the demo code was copied (2021). 

Because I don't know what in USBPD_CAD_Process(), do they run callback? what makes it work for the callback code to be executed?

 

 

 

 

 

 

[Riscy]

I checked the ADC12 setting, which depends on VBUS to monitor; I noted variants in the ADC12 setting between demo code 2021, CubeMX 2024, and host MSC code that STM provided a link to GitHub earlier. 

The RTOS thread for USPD is working fine since it was called twice, which runs the USBPD_CAD_Process(), but the callback function still does not run.   

Without knowing the source code in the USBPD_CAD_Process(), I struggled to make sense of establishing the root cause for not calling a callback. I don't see the ADC12 service in the USPD code to check if this is working correctly. I can see the init code in ADC.c, but it does not link to CC1/CC2. I have looked through documentation UM2552 & AN5418 and the USUD wiki, but it seems outdated for the V1.4.0 library. The demo code 2021 for ADC12 seems to run on its own but not V1.4.0, which is done differently. They do not seem to use CC1/CC2 to ADC12.

Does the USB device depend on CC1/CC2 for proper operation?

Do you have a working device CDC_ACM under V1.4.0/V1.4.1 library from your end?

 

[FBL]

> Does the USB device depend on CC1/CC2 for proper operation?

Indeed, CPP01-M12 is used for power delivery protection in sink applications. 

> Do you have a working device CDC_ACM under V1.4.0/V1.4.1 library from your end?

Unfortunately, no, I will ask this from USBX team.

[Riscy]

"Unfortunately, no, I will ask this from USBX team." I was wondering if they taking up this challenge?

[FBL]

Hello @Riscy 

USBPD_SNK_UX_Device_HID_CDC_ACM application is used only for U585 board.

You can port it to U5A5 and make sure to use dead battery protection and some changes may be required as well.

[Riscy]

Do you have the source code (.c) for USBPD_CAD_Process(), which is missing? Without this, it is challenging to determine the use of power management work with USB code. 

[FBL]

Hello @Riscy 

USBPD_CAD_Process() uses pre compiled static USBPD library.

USBPDCORE_NOPD_CM33_wc32.a

[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!