Managing CubeMX Software versions, IDE, and Firmware Packages

[Stuntman]

Curious if someone could shed some light on the compatibility between versions of CubeMX and "Embedded Firmware Packages".

I have been using an old version of CubeMX (4.25) for some time (>2 years). I am now looking at doing some development with a controller that is not supported with this version of the software. I notice that as of this writing, the updater lists version 5.1, while the ST website lists the latest version of CubeMX as 5.6.1.

My questions:

1. Why does my "Check for Updates" list ver. 5.1 as the latest upgrade while ST shows 5.6.1. Can I not update my version, or is this going to require a clean install to get to the latest version?
2. I have lots of code developed using certain versions of firmware packages. Can I be sure that upgrading to CubeMX Ver 5.1 (or 5.6.1), I can still use my legacy Firmware packages? For instance, one package I have used extensively is STM32F0 Ver 1.9 while I see that 1.10 is available on ST's website.
3. I am currently using TrueStudio (9.0.1) with Cube. Does upgrading CubeMX retain my ability to use this IDE?
4. How does all of this play into possibly porting to CubeIDE if I choose?

In short, I would like to work with some newer MCUs that are not supported by my old software tools. However, I want to make sure that the steps to upgrade doesn't sabotage my library of working code sets.

Thanks

[TDK]

> Why does my "Check for Updates" list ver. 5.1 as the latest upgrade while ST shows 5.6.1. Can I not update my version, or is this going to require a clean install to get to the latest version?

Probably once you update to 5.1 there will be an option to then update to 5.6.1. Sometimes it doesn't make sense to support upgrading from anything to everything from a support standpoint. v4 is quite old.

> I have lots of code developed using certain versions of firmware packages. Can I be sure that upgrading to CubeMX Ver 5.1 (or 5.6.1), I can still use my legacy Firmware packages? For instance, one package I have used extensively is STM32F0 Ver 1.9 while I see that 1.10 is available on ST's website.

Version 1.11 is actually the latest. You can select old versions for use. For F0, it still gives me an option to download verison 1.0 of the library. However, support and development is focused on new features, not supporting old versions. You may run into issues. HAL is not completely backwards-compatible--some structures change, although it is generally straightforward to make changes when updating to the newer version.

> I am currently using TrueStudio (9.0.1) with Cube. Does upgrading CubeMX retain my ability to use this IDE?

TrueStudio is still a supported code generation platform. Presumably IDE version doesn't matter, not sure.

> How does all of this play into possibly porting to CubeIDE if I choose?

You can use STM32CubeIDE independent of STM32CubeMX, although they make it somewhat nice to combine the two. The later versions of CubeMX support CubeIDE better.

I don't think re-generating code in CubeMX is the right way to develop a project. Maybe generate once at the outset and then update as needed. That part is up to you though.

> However, I want to make sure that the steps to upgrade doesn't sabotage my library of working code sets.

Backup your work and archive it so you can return to old versions should something go wrong. I would not count on STM32CubeIDE not overwriting anything when re-generating code.

[Stuntman]

@TDK​ 

Thanks for the reply. You included lots of valuable information.

Couple pieces I would like some clarification if you don't mind:

However, support and development is focused on new features, not supporting old versions. You may run into issues. HAL is not completely backwards-compatible--some structures change, although it is generally straightforward to make changes when updating to the newer version.

My assumption was that is that the CubeMX handled the GUI and boilerplate operation, while the firmware packages themselves (ie STM32F0 Ver 1.9) supplied the code (however they handle piping in the CubeMX configurations). My hope was as long as you could operate with the version of firmware packages, the generated could should be identical. True? Put another way, I was curious if you are suggesting that a newer version of CubeMX, utilizing Ver 1.9 software package could give slightly different generated code, or if you are implying that someday, CubeMX ver 6.xx may not support my old STM32F0 ver 1.9, and then I would need to do some transitioning to the latest packages.

I don't think re-generating code in CubeMX is the right way to develop a project. Maybe generate once at the outset and then update as needed. That part is up to you though.

Simply put, I have done this often, and based on the comment cues in the code, was under the impression this was how it CubeMX was meant to be used. Are you suggesting that I am asking for bugs in continuing to do so? Perhaps you are fleshing out my concern, where I have kept my old version of CubeMX and I can change settings as needed and regen code (generally) without issue. I don't want to update version of CubeMX and fight bugs whenever this happens.

[TDK]

> My hope was as long as you could operate with the version of firmware packages, the generated could should be identical. True?

You could be right. There are bugs in the generation that crop up with new versions, like clocks not getting enabled, or things getting initialized out of order. Not sure if that's the fault of CubeMX or the repository or something else.

> if you are implying that someday, CubeMX ver 6.xx may not support my old STM32F0 ver 1.9

No idea, but most things become obsolete eventually.

> was under the impression this was how it CubeMX was meant to be used. Are you suggesting that I am asking for bugs in continuing to do so?

Well if you do it once, and it works, it'll probably work if you regenerate the code again. I think switching from one version to another may have a higher chance of introducing bugs. If it were my project, I wouldn't update to the latest version just because it exists. Sounds like you are looking for increased functionality, which is a better reason.

Just my opinion. I don't work for ST.

[Stuntman]

@TDK​ 

Thanks for your take on this.

It sounds like it may not be immune to a few bugs, but not necessarily probable.

For reference, in case someone else is having similar apprehensions towards upgrades: I noticed that CubeMX allows you install a Firmware Package from a local source (.zip file). Therefore, I have backed up both my installer for CubeMX4.25 as well as the the firmware packages (which seem to already be backed up in the C:\Users\xxprofilexx\STM32Cube ) so i should able to revert if absolutely necessary . I will likely run a document compare on the main.c of any project I regen code for, just to see if there are blatent issues.

I wouldn't update to the latest version just because it exists.

Could not agree more.

Thanks again for the insight.