STM HAL and Middleware versions

[RVikt]

What is the proposed workflow on keeping a platform updated with the latest releases of for example HAL and middleware layers from ST? Previously the code generated from CubeMX contained a version and a date, but that seems not be in the header of the generated file anymore with the last generation from CubeMX that I performed. How can I refer to which version of let say the usb core that I am using?

[Khouloud ZEMMELI]

Hello @RVikt​ ,

Using the latest CubeMX version you will be on the latest version of FWs and MWs , and you will get the message to download the latest FW version if it does not exist on your repository.

Best Regards,

Khouloud

[alister]

In early development and home projects, it may well improve something.

But otherwise it's unprofitable to upgrade without cause... The new FW or tools might regress or change, you'd have to isolate, fix theirs or change yours, completely re-test, without reviewing every change to the FW the cost to your productivity would be unknown and you couldn't know with the tool change. If your development is near completion, your management and marketing teams won't thank you if it causes delay. If your development is in maintenance, your customers won't thank you or pay you for this, and if your testing isn't complete and something bad happens, may hate you for it.

[Pavel A.]

If you use "all-in -one" Cube packages, note that since a year ago or so, the middleware components are available on github in separate repositories. Look here.

The USB core, for example, is in two libraries: USB device and USB host.

So all you have to do is read the release notes of the "all-in -one" package and find versions of sub-components.

Write this info down in your development notes.

CubeMX/IDE templates used to generate code are versioned independently from the libraries, so you need to find which range of "all-in-one" Cube library versions is compatible with which CubeMX/IDE version (a bonus task!)

-- pa