STM32CubeMX Generates MX_LWIP_Init even when disabled

[AAlis.23]

STM32CubeMX always generates the function MX_LWIP_Init even when its generation is disabled. This causes a redefinition during compilation if a custom implementation already exists. On every regeneration the autogenerated file re inserts the function and its prototype, triggering the conflict.

Board: Custom

CPU: STM32H743IITx

[Mahmoud Ben Romdhane]

Hello @AAlis.23 ,

 

Let met thank you for posting.

For more investigation, I suggest please that you provide your Ioc.File.

 

Thanks.

Mahmoud

[AAlis.23]

Hi, attached.

Thanks

[AAlis.23]

Attached a video with the problem. CubeMX updated to 6.15.

[Mahmoud Ben Romdhane]

Hello @AAlis.23 ,

 

Thank you for your quick clarification.

I created from scratch a project with STM32H743IIT6 and I enabled LWIP.

While disabling the generation of MX_LWIP_Init on STM32CubeMX, you can notice that the function does not exist on main.c and the build is finished with 0 errors.

 

In fact, the expected behavior is to find the function initialisation on lwip.c

Further to the Screen Recording, I noticed that you added code line between

/* USER CODE BEGIN 2 */

/* USER CODE END 2 */ 

And after the generation, the part line placed between the /* USER CODE BEGIN  */ and /* USER CODE END */ is not being deleted.

 

Thanks.

Mahmoud

[AAlis.23]

Hi Mahmoud,

Thanks for the follow-up.

Actually, it's not expected for the initialization code to be placed in main.c — in fact, CubeMX doesn't place any peripheral initialization code directly in main.c. Each peripheral has its own .c file where its respective MX_XXX_Init function is generated, such as MX_GPIO_Init in gpio.c, or MX_DMA2D_Init in dma2d.c. The only functions typically generated in main.c are SystemClock_Config and MPU_Config.

So in that sense, it's perfectly correct for the LWIP initialization to be placed in lwip.c.

Now, if you explicitly disable the generation of MX_LWIP_Init in CubeMX, then naturally that function should not be generated. Otherwise, what would be the point of having the option to disable it in the first place?

In my case, I’m placing my own initialization code in the only appropriate place available — between the /* USER CODE BEGIN */ and /* USER CODE END */ blocks. Based on all this, I still believe this is a bug.

I'd really appreciate it if you could try placing your own initialization function between the USER CODE blocks and let me know if it fails to compile due to a duplicate definition. If that’s the case, how are we supposed to add custom initialization code if CubeMX doesn't properly respect the option to not generate it?

Thanks again,

[AAlis.23]

@Mahmoud Ben Romdhane 

Any update? I updated to the last versions and the problem persist.

Thanks

[Pavel A.]

@AAlis.23 Your .ioc has "Generate peripheral initialization as a pair of '.c/.h' files per peripheral" checked.

This is why MX_LWIP_Init is placed in separate file lwip.c/h (along with other per-module files) rather than in main.c.

"Generate code" checkbox for LwIP is unchecked and "Delete previously generated files when not re-generated" is selected. So the remaining question is why lwip.c has not been deleted after re-generation. Maybe because it contains modified user code besides the MX_LWIP_Init().

 

[AAlis.23]

Hi,

These are actually two different things.

One is choosing to generate code as separate .c/.h files per peripheral, which is generally helpful when sharing peripheral code or changes across multiple applications. That option is intentional and beneficial in many scenarios.

However, a completely different matter is disabling the code generation for a specific module like LwIP. If I've explicitly unchecked the "Generate code" option for LwIP, then MX_LWIP_Init() shouldn't be generated at all, regardless of whether the code is structured in separate files or placed directly in main.c. That function simply shouldn't appear anywhere. This seems to be a clear bug in the application.

It's also quite frustrating, just like many other persistent issues that users have been reporting for years without resolution. A well-known example is the one where programming the MCU always causes a random file to open and take focus, which interrupts the workflow. This bug has been around forever, and it's probably the most reported one in the forums.. still unsolved.

Best regards,