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

[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,