Bug or ill advised design choice: converting between pairs of .c/.h and a monolith strips user code.

[Andrei Chichak]

Environment: Intel Mac, 12.7.6, CubeIDE 1.18.0, Device firmware STM32Cube FW_F4 V1.28.1 and others

I noticed that when I converted my project to use .c/.h pairs for device initialization, all of the custom peripheral initialization code got stripped. This lead to a week of debugging of "what did I break?"

When using TouchGFX, the designer tool modifies the peripheral setup code to add in a whole bunch of custom code to setup and start devices like external RAM, FLASH, display controllers, and I2C devices. But if you convert your project to use .c/.h pairs, all of this code gets stripped and you end up with a long series of hard faults (accessing memory that isn't enabled), and a black screen (display controller never got turned on).

I noticed that other customers were complaining about similar symptoms in the context of FreeRTOS and TouchGFX back in 2022 and there was an internal ticket generated. Well, the issue it still there and it has nothing to do with the use of FreeRTOS or TouchGFX.

You can duplicate this by starting a project with, say, a STM32F407F-DISC1 board. Generate code. Compile, just for kicks. Munge main.c in MX_GPIO_Init, modify it to read:

  /* USER CODE BEGIN MX_GPIO_Init_1 */
  uint32_t fu;
  fu = 42;
  /* USER CODE END MX_GPIO_Init_1 */

Save, compile, see the warning about "fu" not being used.

Next, <Project Manager><Code Generator> enable "Generate peripheral initialization as a pair of '.c/.h' files per peripheral. Save, generate code, look in gpio.c, notice that the user code block is gone. You can try this in the I2C section as well, same result even though the user code block exists in i2c.c. I've seen this happen with U5 processors in octospi, dsihost, hspi, and ltdc, basically anywhere there was USER CODE blocks being used. This leads me to believe that it has nothing to do with the processor family or which peripheral USER CODE block was being used.

Converting back to a monolith, with all of the startup code in main.c, does the same thing, USER CODE gets stripped.

Although, you won't get any complaints about 'fu' not being used, so that's a good thing ;) .

Andrei (a neighbour from The Great White North)

[Andrew Neil]

This came up a while back.

I think the choice of .c/.h pairs vs all-in-main is just supposed to be a one-off setting at the start of a project - I don't think it's intended to be able to change an existing project?

PS:

Found it:

https://community.st.com/t5/stm32cubemx-mcus/cubemx-does-not-split-main-c-into-individual-device-files/m-p/779979

Seems to be awaiting a rely from @Ghofrane GSOURI 

[Andrei Chichak]

The initial state of the project, with custom code, may be done by TouchGFX Designer where you have no choice in project layout.