STM32Cube MX Version Compatibility

[JKova.3]

I previously had STM32CubeMX V6.2.1 installed on my machine. I then tried to work on another project that my colleague made and my machine said I would need to “Continue�? or “Migrate�? because I didn’t have STM32CubeMX V6.5.0 installed. So then I updated to the latest Cube MX version (STM32CubeMX V6.8.0) because that’s the only version it would let me update to.

Now feeling like I would have a good chance at victory I opened the same project up and got this:

If I click “Continue�? or "Migrate" I get an error message about a GDSC error in the toolchain and it doesn’t load at all.

 

So what are my options here? I could figure out how to install version V0.6.5 and it should come good. However this could turn into a nightmare with different workers at our company using different versions to to edit cube files. It would be tedious if they need to download a certain version of STM32 cube for project that they work on. Thoughts?

[Bob S]

All developers on a project must be running the same version of CubeMX. You can manually download CubeMX 6.5 from the ST web site and install it. https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-configurators-and-code-generators/stm32cubemx.html

You may then need to download the older version of the F0 lib that the project uses, but that should be do-able from inside CubeMX

[Tesla DeLorean]

>>It would be tedious..

But probably necessary to avoid differences in code generation, etc.

Historically all source needed to build things should be under source code control, so you can come back in months, weeks, years and be able to create the same code and come up with minimal fixes, or understand the nature of reported failings.

One approach would be to not constantly churn the tools and their associated libraries, etc.

The model of repetitive code (re)generation is ill suited to groups of coders using disparate tool/library versions. Not sure how you address this without rules and expectations. Or without perhaps having a fork you maintain and merge in changes, and not permit regeneration or new libraries. Partition code such that developers can focus on their own sub-set of functionality until its ready to merge.

[Pavel A.]

Having several people working together and be productive always is a challenge.

Some points...

> error message about a GDSC error

This means that you've selected generation of a makefile project (not Eclipse/CubeIDE or Keil or IAR). Is this what you use? IIRC this option has been changed in some recent Cube version. In v. 6.8 it is called "makefile".

Every CubeMX update consists of two parts: (1) code generation rules and templates and (2) the "HAL" and "middlewares" library version for which the former generates code.

The part (2) is available via the package manager tool of CubeMX and CubeIDE.

Also it is available on github, where you can get previous versions and track changes as usual with git.

Any of these changes can be breaking., as you understand.

​Usually you want to provide common set of tools and libraries to everyone.

Fortunately, all the parts, CubeMX, CubeIDE and the libraries support installing several versions side by side so developers can use different versions for different projects. This is not hard but needs attention.

You can download all needed files for your team and provide training.

[JKova.3]

Thanks for the responses guys. We were using the GDSC file to import the cube project into Visual GDB. I think having different versions of CubeMX installed and keeping a log of which project is using what is probably going to be the best way forward for us (as suggested by Pavel).