How to detect STM32CUBEIDE version in STM project?

[dikene]

Hello,

I want to compile STM projects sent to the automation program. The developed projects are created using different versions of STM32CubeIDE, such as STM32CubeIDE 1.6, 1.9, or 1.16. When I tested it manually and provided the IDE version information to the program, it successfully compiled the project using the correct IDE version. Program using stm32cubeidec.exe for compile.

So, how can the automation process detect the IDE version from within the project? When I scanned the files in the project, I couldn’t find anything that stores the IDE version information.

My second question is: if I compile all projects using the latest version of STM32CubeIDE (1.16), would that cause any issues? Is the IDE version important?

[AScha.3]

Hi,

The IDE version by itself has no impact on the program you generate, afaik.

BUT the used version of HAL, compiler, tool chain, CubeMx IS important. Especially if you have a program, generated with an old IDE version ( and old HAL version) and now want change something in the program with a more recent version: IDE ask you then: continue with old version or migrate to actual one.

So to check the used Cube version, you can open the IOC file with an editor and look for the used Cube version... 

But to be 100% sure, to generate exactly same again, you should use something like an snapshot of the old system.

[dikene]

Thank you for your response.

I can compile the project headless with stm32cubeidec.exe. As you said, no error occurred when compiling a project created with version 1.9 with the stm32cubeidec.exe program belonging to version 1.16. But the two hexes created were different from each other. In this case, can I trust the hex compiled with the new version?

[AScha.3 · Accepted solution]

Trust is not the right word here.

Test is the word.... without full function test, you can't trust in anything new; and you made a new program version here.

Usually (!) it's working fine, but if you not lucky, the new version of HAL has an error somewhere, the old didn't have it.

And don't forget the optimizer settings, if you want about same output, use same settings as in the old project.

So trust: no. Test: yes, then you can trust.