CubeMX generated code error when using BSP code

Giovanni1 · ‎2025-01-22

Hello all.

I'm new here, this is my first post.

I found a problem with STM32CubeIDE.

I don't know where to post errors report, so please move this post if this is the wrong place.

I'm a skilled embedded programmer, but I've worked till now on 8 bit microcontroller (AVR, PIC, STM8, Z80, etc.).

Now we (me and my company) are moving to the ARM platform, and I choose STM32 as our next family of MCU/MPU.

We need two different platform, for different devices: an high performance one, for which I choose the Cortex-M33 (STM32H5 family) and a low power, low cost one, for which I choose instead the STM32C0+ (STM32C071).

I bought few NUCLEO boards, so I can learn the new ecosystem in an easy way.

I installed STM32CubeIDE, complete with CubeMX.

I created a new STM32 project, using the board selector I choose the NUCLEO-H563ZI board.

Using CubeMX I configured the board; I also enabled BSP HMI code generation, and enabled User Leds.

I decided to use ThreadX and NetXDuo.

Now, there's a little problem: When I create the CubeMX code, there's an error in the main() function generated by CubeMX.

The CubeMX code generator insert the instruction "MX_ThreadX_Init()" before the BSP initialization code, just below the "USER CODE END 2" comment; so, User Leds and virtual coms do not work, since their initialization code is never executed (once you call MX_ThreadX_Init() it never returns);

I have to manually move it from there to just before the "while (1)" statement at the end of main().

This is not a big problem, but is an annoying one; for a beginner it can frustrating.

Here below an extract of the main() code generated by CubeMX:


  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_ETH_Init();
  MX_ICACHE_Init();
  /* USER CODE BEGIN 2 */

  /* USER CODE END 2 */

  MX_ThreadX_Init();

  /* Initialize leds */
  BSP_LED_Init(LED_GREEN);
  BSP_LED_Init(LED_YELLOW);
  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();
  }

  /* We should never get here as control is now taken by the scheduler */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {

    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */

You can see, at line 14, the MX_ThreadX_Init() instruction, that should instead be located under line 34.

Mahmoud Ben Romdhane · ‎2025-01-22

Hello @Giovanni11,

First let me thank you for posting and welcome to the ST Community.

Your request is under investigation, and I will get back to you ASAP.

Thanks.

Mahmoud

Andrew Neil · ‎2025-01-22

As a workaround, you can set CubeMX to not generate the calls to the init functions - so then you can insert them in the order you choose:

https://community.st.com/t5/stm32cubemx-mcus/how-to-have-cubemx-configure-a-peripheral-but-not-enable-it/m-p/761680/highlight/true#M30800