Closed builder60 closed 1 month ago
Hello @builder60,
Thank you for your report. This issue has been tracked internally. ST Internal Reference: 192900
With Regards,
Hello @builder60,
Is there any specific reason for closing this issue, or is it considered invalid?
With Regards,
I was asked to close a previous issue once it was given an internal tracking number. I understood that to be the procedure. This is still a valid issue.
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
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)
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.