STM32U5A5 (Cube 1.14.1): CDC_ACM & USB_HS with USBX issue with CSRST not self clearing

[Riscy]

I have an eval board (Nucleo STM32U5A5) working with the CDC_ACM demo code (UCPD/USB_HS, which was written in 2021). I then created the CDC_ACM from scratch with the majority of IOC parameters's configuration copied over from the demo IOC and MOOC tutorial (for STM32H7xxxx); I noted many new parameters in the 2024 release, which I left untouched. I then copied over some USB code filename (using WinMerge) into new code (as suggested by MOOC for STM32H7xxxx). I refer to this as a new code/project.

I found an issue with the static HAL_StatusTypeDef USB_CoreReset(USB_OTG_GlobalTypeDef *USBx); it times out after the core reset: CSRST is not cleared in the new code. However, the demo code does. 

I have checked the RCC/PWR/USB/UCPD register flags (via SFR window) while under the breakpoint in USB_CoreReset and found all the same between the demo code and new code except the TYPEC_VSTATE_CC2 which shows 1 in the demo code but 0 in the new code. 

I have reviewed the datasheet and manual to figure out what factors are preventing CSRST from being cleared after the core reset. I'm open to suggestions for ways to resolve this or something missing in the IOC setup.

Have you tried the new CDC/ACM project based on the revised CubeIDE/MX release?

PS: I have also applied the CDC_ACM/USBX project into the application test code (containing FileX/ThreadX/etc), which also has the same issue with CSRST. I have spent two days trying to fix this.  

I am going to check CC1/CC2 later on. Does it hold up the CSRST?

[FBL]

Hello @Riscy 

I think you have already fixed this issue with missing __HAL_RCC_SYSCFG_CLK_ENABLE(). Could you please confirm?

[Riscy]

Yes I can confirmed but not sure why it not present in V130 library with working USBX. However in V140/141 it did not start the USB.  

[FBL]

Hello @Riscy 

Here is a screenshot from debug view using latest version V1.4.0

Your issue is more likely linked to the version of CubeMX or the implementation. Would you share a failing and working project?

[Riscy]

Hi

Attached is the non-working USBX under V140/V141

I have fixed the 1st issue where the peripheral is not activated for USB configuration. This code was not present in the (believed to be) V130 library (a working version from the demo example).  

__HAL_RCC_SYSCFG_CLK_ENABLE();   (see HAL_PCD_MspInit())

It failed to start USB because it did not detect the power. I unable to debug why it does not invoke USB start because the source code is missing. See USBPD_CAD_Process()

I can see USBPD_CAD_Process() is used in V130 but not in V140 (from the assembly code). Both has missing source code USBPD_CAD_Process().

Can you share me a link for your working V140 version?, I like to investigate differences. 

The IDE 1.14.1 and CubeMX 6.10.0-RC9 is up to date up to 1st Feb 2024.

[FBL · Accepted solution]

Hello @Riscy 

I confirm the issue on myside, and it is linked to CubeMX code generation. This issue is reported to dedicated team.

Internal ticket number: 174247 (This is an internal tracking number and is not accessible or usable by customers).

[Riscy]

Thank you for processing this issue. Can you ask the team to generate a working solution in the form of a demo code or an example-based CDC_ACM based on the V140/141 setup for STM32Cube IDE/MX for the U5A5 device? I think the changes from V130 to V140 are moderate due to power management. If possible, update the tutorial so it is easier to integrate existing code via CubeMX and code to add in. I can test that for you.

In context of USBPD_CAD_Process(), do you have the original assembly code with comments and an explanation or how to find it

Thank

[FBL]

Hello @Riscy 

STM32CubeU5/Projects/NUCLEO-U5A5ZJ-Q/Applications/USBX/Ux_Device_CDC_ACM at main · STMicroelectronics/STM32CubeU5 (github.com)

Do you mean this example ?

[Riscy]

Yes, that is correct. It did say a mixture of V120 and V130 there.

The current revision today is V141; I can see moderate change from earlier in the way CubeMX generates them. It would be great to have it updated demo of V140/V141 if possible. 

[FBL]

Hello @Riscy 

It is typical for Middleware to only update when there are real bugs or issues as listed in readme.

Updating the middleware revision solely according to Cube Firmware revision can mix things up and cause confusion to everyone to keep track and follow up.

To better understand your inquiries, would you please direct me with links to be more efficiently. For example, direct me to github link instead of V120 V130 V140/V141 etc... 
Thank you for your understanding.