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]

Hi @Mahmoud Ben Romdhane, have you read my last answer? Did you find a solution? Thanks

[Mahmoud Ben Romdhane]

Hello @AAlis.23 ,

After checking internally the initialisation of MX_LWIP_Init should not generated on lwip.c file.

This behavior exists with other Middleware and Software Packs.

Thank you for bringing this issue to our attention.

An internal Ticket was submitted to the Development Team (Internal Ticket Number: 218134).

I will keep you up to date when the problem is solved.

Thanks.

Mahmoud

[AAlis.23]

Hi Mahmoud,

Thank you very much for your message and for the follow-up.

I'm really glad to be able to contribute in some way to improving tools like CubeMX, it's always rewarding to help, even if just a little. I'll be looking forward to hearing back once the issue is resolved, and if there's an update released, I’d appreciate it if you could kindly let me know so I can install it right away.

And now that I’ve found this bug… I guess the next step is for me to become CTO or something, right? :D

Thanks again and best regards

[AAlis.23]

@Mahmoud Ben Romdhane 

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

Thanks