Correct Git strategy for STM32CubeMX2 projects

[mgandi]

Hi,

I am working on a new Project for the STM32C562MET6 with STM32CubeMX2 and VS Code.

On the first run of toolchain generation, CubeMX generates all expected folders like arch, generated, stm32c5xx_dfp and stm32c5xx_drivers.

But I dont want to version all files if they can be generated so i added the folders above to the .gitignore file.

After running it a second time but with those folders missing, CubeMx2 doesnt generate it. I already tried to set the “conflict handling rules” to override. 

Any suggestions?

 

[Sara BEN HADJ YAHYA]

Hi ​@mgandi, and welcome to the ST Community,

This behavior is not related to the .gitignore file. It is part of the code regeneration logic in STM32CubeMX2.

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

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

Regards,

Sara.

[mgandi]

Hi ​@Sara BEN HADJ YAHYA ,

the problem is not a modified file.

The “generated” folder for example is generated by the CubeMX2 IDE generation and is not touched by the developer at all, so its not Git versioned since it can be re-generated.

Steps:

1. Developer #1 creates ioc2 file and generates IDE (all folders where generated)
2. Developer #1 adds and commits user source code and ioc2 file
3. Developer #2 wants to continue work on a different machine and clones the repo
4. Developer #2 opens CubeMX2 to generate the missing files
5. Problem → CubeMX2 does not generate them

ioc2 in empty folder → everything is generated

delete e.g. the “generated” folder and re-run IDE generation → no folder generated.

[Sara BEN HADJ YAHYA]

Hi ​@mgandi ,

Thank you for the detailed description.

What you are observing is expected behavior in this case. The .settings folder contains the exported-files.json file, which STM32CubeMX2 uses to track the previously generated content. If this file is present, STM32CubeMX2 will not trigger the regeneration of missing generated files.

Please add the .settings folder to your .gitignore, so it is not versioned in Git.

This ensures that when another developer clones the project and opens it in STM32CubeMX2, the missing generated content can be properly recreated.

Regards,

Sara.

[Pavel A.]

> But I dont want to version all files if they can be generated

IMHO the generated files (but not the files copied by CubeMX from the Cube library package) should be treated as “precious artifacts” and committed to version control, exactly like files generated by AI tools (cursor, codex and so on).

The reason for the latter is that the generation is “non-deterministic”. Even though CubeMX is not AI (yet), one can consider its generation non-deterministic too, because the rules or templates can change with CubeMX updates.

Now, if you agree with this argument, just check the generated files in, and be happy, the whole team.

 

[unsigned_char_array]

IMHO the generated files (but not the files copied by CubeMX from the Cube library package) should be treated as “precious artifacts” and committed to version control, exactly like files generated by AI tools (cursor, codex and so on).

I agree. We add those to source repository so builds can always be reproduced without a specific CubeMX version installed. You just need the ARM toolchain. Though we also add the copied driver files. Arguably those should be in a submodule (self hosted, not depending on third party hosting).