STM32H5: CubeMX generates USBX device stack init function but never calls it

[KaiY]

I found what looks like a reproducible STM32CubeMX code generation bug for STM32H5 USBX device projects.

I tested this on a fresh project, so this does not appear to be a migration issue from an older codebase.

Problem

CubeMX generates these USBX init functions:

• MX_USBX_Init()
• MX_USBX_Device_Init()
• MX_USBX_Device_Stack_Init()

However, the generated call flow only invokes:

• MX_USBX_Init()
• MX_USBX_Device_Init()

and never calls MX_USBX_Device_Stack_Init().

That is a problem because MX_USBX_Device_Stack_Init() contains the actual device stack setup:

• ux_device_stack_initialize(...)
• class registration
• ux_dcd_stm32_initialize(...)

Without that function running, the USB peripheral can start and receive a reset interrupt, but USBX has not been given valid device framework pointers yet.

Observed failure

When USB_DRD_FS_IRQHandler() fires and the USB reset path runs, the code eventually reaches:

• HAL_PCD_ResetCallback()
• _ux_dcd_stm32_initialize_complete()
• _ux_utility_descriptor_parse(...)

and hard faults inside _ux_utility_descriptor_parse, because the device framework pointer was never initialized.

In my case the hard fault occurred at the byte dereference in _ux_utility_descriptor_parse().

Generated code pattern

MX_USBX_Init() does:

• ux_system_initialize(...)
• MX_USBX_Device_Init(...)

but does not call MX_USBX_Device_Stack_Init().

MX_USBX_Device_Stack_Init() is generated correctly, but left unused.

Expected behavior

The generated code should call MX_USBX_Device_Stack_Init() after ux_system_initialize(...) and before MX_USBX_Device_Init(...), so the order is effectively:

1. ux_system_initialize(...)
2. MX_USBX_Device_Stack_Init()
3. MX_USBX_Device_Init(...)
4. USB thread configures PMA and starts PCD

Workaround

Manually add the missing call so that MX_USBX_Init() does:

if (ux_system_initialize(pointer, USBX_MEMORY_STACK_SIZE, UX_NULL, 0) != UX_SUCCESS)
{
 return UX_ERROR;
}
if (MX_USBX_Device_Stack_Init() != UX_SUCCESS)
{
 return UX_ERROR;
}
if (MX_USBX_Device_Init(byte_pool) != UX_SUCCESS)
{
 while(1)
 {
 }
}

Why I believe this is a CubeMX bug

I reproduced this with a brand-new test project generated from scratch, not just an upgraded older project.

Has anyone else seen this on STM32H5 + Azure RTOS USBX device projects, and can ST confirm whether this is a known generator issue?

If needed, I can also post the exact generated files showing the missing call path.

 

[Ghofrane GSOURI]

Hello @KaiY 

I'm currently investigating this behaviour. I will get back to you as well as possible.

Thx

Ghofrane 

[Ghofrane GSOURI]

Hello @KaiY 

After creating a from scratch IOC using the latest version of STM32CubeMX 6.17.0 and generating the code , the mentioned call above is generated successfully as shown below 

THX

Ghofrane

[KaiY]

My test project does not have this code.
Perhaps it's with certain project settings?

Here is a screenshot and my .ioc file

[Ghofrane GSOURI]

Hello @KaiY 

After reviewing your IOC configuration, I compared it with the available examples and found that the Ux_Device_HID example is very similar to your setup.

In this example, the following code is present in the generated sources:

 if (MX_USBX_Device_Stack_Init() != UX_SUCCESS)
 {
 /* USER CODE BEGIN MAIN_INITIALIZE_STACK_ERROR */
 Error_Handler();
 /* USER CODE END MAIN_INITIALIZE_STACK_ERROR */
 }

This check is not inserted automatically by the code generator and must be added manually in the user code section inside app_ux_device_thread_entry, as shown in the following screenshot.

THX

Ghofrane