Call to MX_ThreadX_Init() inserted in wrong place

[builder60]

Caution

The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post your report to the ST Community in the STM32 MCUs dedicated page.

Describe the set-up

• NUCLEO-U5A5ZJ-Q
• STM32CubeIDE

Describe the bug (skip if none)

Generated code in main.c inserts the call to MX_ThreadX_Init() prior to the code for Bsp initialization:

/* USER CODE END 2 */

MX_ThreadX_Init();

/* Initialize leds */
BSP_LED_Init(LED_GREEN);
BSP_LED_Init(LED_BLUE);
BSP_LED_Init(LED_RED);

/* Initialize USER push-button, will be used to trigger an interrupt each time it's pressed.*/
BSP_PB_Init(BUTTON_USER, BUTTON_MODE_EXTI);

/* Initialize COM1 port (115200, 8 bits (7-bit data + 1 stop bit), no parity */
BspCOMInit.BaudRate = 115200;
BspCOMInit.WordLength = COM_WORDLENGTH_8B;
BspCOMInit.StopBits = COM_STOPBITS_1;
BspCOMInit.Parity = COM_PARITY_NONE;
BspCOMInit.HwFlowCtl = COM_HWCONTROL_NONE;
if (BSP_COM_Init(COM1, &BspCOMInit) != BSP_ERROR_NONE)
{
Error_Handler();
}

MX_ThreadX_Init(); /* Should be here /
/ We should never get here as control is now taken by the scheduler */

/* Infinite loop */

How to reproduce the bug (skip if none)

1. Indicate the global behavior of your application project
2. List the modules that you suspect to be the cause of the problem (Drivers, BSP, MW...)
3. Describe the use case that generates the problem
4. How we can reproduce the problem

Additional context

If you have a first analysis, an enhancement, a fix or a patch, thank you to share your proposal.

Screenshots

If applicable, add screenshots to help explain your problem.

[ASEHSTM]

Hello @builder60,

Thank you for your report. This issue has been tracked internally.
ST Internal Reference: 192900

With Regards,