Skip to main content
Associate
September 12, 2026
Solved

Observations: CubeMX2 1.1.1 will not restore deleted main.c (different behavior compared to CubeMX6)

  • September 12, 2026
  • 2 replies
  • 85 views

Software version: STM32CubeMX2 1.1.1 Target MCU: STM32C542RCT6

Steps I followed:

  1. Created a new project and generated the CMake‑based IDE project to a target folder.
  2. Closed CubeMX2, then manually deleted Core/Src/main.c via file explorer.
  3. Opened the original .mx2 project file again, kept using the same output directory, and clicked Generate IDE project.

Observed behavior: After code generation finishes, main.c is still missing from the folder. There is no warning message or popup to notify me the main entry‑point file is absent. Consequence: CMake build fails with undefined reference to main.

In legacy CubeMX6, when main.c was removed, code‑generation would recreate this template file automatically. This does not happen in CubeMX2 1.1.1.

Current workaround: I have to generate project files into a brand‑new empty folder to get a fresh copy of main.c, then copy this file back to my original project directory.

Analysis: It seems CubeMX2 treats main.c as a user‑modified file and skips regeneration. However it does not handle the scenario where the file has been manually deleted from disk. Developers coming from CubeMX6 may not expect this difference in behavior and can run into build issues. It would be helpful to add a warning if main.c is missing.

Best answer by Oussama_TROUDI

Helo ​@hao cheng and welcome to the ST Community,

In STM32CubeMX2, user modifications are handled differently than in the classic STM32CubeMX flow.

The conflict rule is only applied when both conditions are met:

  • The file was changed outside STM32CubeMX2, and
  • The same file is also updated again from inside STM32CubeMX2

So, to summarize the three cases:

  1. If the file was changed outside the tool, but nothing was changed in the tool, then no conflict rule is applied.
    In this case, the user changes are kept, even if the file is deleted, so it will not be regenerated.

  2. If the file was changed outside the tool and then you modify the related configuration in STM32CubeMX2, then the conflict handling is triggered.
    At this stage, you will be prompted to choose whether to keep your changes backup or overwrite them.

  3. If the file was not changed outside the tool, but you update something in STM32CubeMX2, then the file will be overwritten with the new content.

Example

Take mx_rcc.c:

  • If you add or remove code manually in that file and then regenerate without changing RCC settings in STM32CubeMX2 UI, nothing happens and your code is kept.
  • If you add or remove code manually and also change an RCC parameter in STM32CubeMX2 UI and regenerate, then STM32CubeMX2 applies the conflict rule.
  • If you only use STM32CubeMX2 to update settings and do not modify the file externally, then the generated code will be overwritten.
     

For more details, refer to IDE project regeneration

Workaround for restoring main.c:
As an alternative to generating the project in a new directory, you can remove the generation metadata file: ”settings/exported-files.json”

Please do not hesitate to get back to me if you need more details or further assistance.

Best Regards
Oussama

2 replies

Oussama_TROUDI
Oussama_TROUDIBest answer
ST Technical Moderator
September 16, 2026

Helo ​@hao cheng and welcome to the ST Community,

In STM32CubeMX2, user modifications are handled differently than in the classic STM32CubeMX flow.

The conflict rule is only applied when both conditions are met:

  • The file was changed outside STM32CubeMX2, and
  • The same file is also updated again from inside STM32CubeMX2

So, to summarize the three cases:

  1. If the file was changed outside the tool, but nothing was changed in the tool, then no conflict rule is applied.
    In this case, the user changes are kept, even if the file is deleted, so it will not be regenerated.

  2. If the file was changed outside the tool and then you modify the related configuration in STM32CubeMX2, then the conflict handling is triggered.
    At this stage, you will be prompted to choose whether to keep your changes backup or overwrite them.

  3. If the file was not changed outside the tool, but you update something in STM32CubeMX2, then the file will be overwritten with the new content.

Example

Take mx_rcc.c:

  • If you add or remove code manually in that file and then regenerate without changing RCC settings in STM32CubeMX2 UI, nothing happens and your code is kept.
  • If you add or remove code manually and also change an RCC parameter in STM32CubeMX2 UI and regenerate, then STM32CubeMX2 applies the conflict rule.
  • If you only use STM32CubeMX2 to update settings and do not modify the file externally, then the generated code will be overwritten.
     

For more details, refer to IDE project regeneration

Workaround for restoring main.c:
As an alternative to generating the project in a new directory, you can remove the generation metadata file: ”settings/exported-files.json”

Please do not hesitate to get back to me if you need more details or further assistance.

Best Regards
Oussama

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
hao chengAuthor
Associate
September 18, 2026

Thank you.