cancel
Showing results for 
Search instead for 
Did you mean: 

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

Riscy
Senior

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)

{

1 ACCEPTED SOLUTION

Accepted Solutions

> 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.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

14 REPLIES 14
FBL
ST Employee

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?

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Riscy
Senior

Riscy_0-1706215769186.png

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. 

Riscy_1-1706215787574.png

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
Senior

Riscy_0-1706298288357.png

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). 

Riscy_1-1706298465697.png

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
Senior

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?

 

> 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.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Riscy
Senior

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

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.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Riscy
Senior

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
ST Employee

Hello @Riscy 

USBPD_CAD_Process() uses pre compiled static USBPD library.

USBPDCORE_NOPD_CM33_wc32.a

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.