STM32CubeIDE: how to avoid losing Middleware code changes (USB)

[fbar]

Hello,

I plan to modify the USB Audio Class for a project created in STM32CubeIDE and using the USB Middleware library. I select the peripherals I need in the Device Configuration Tool, plus the USB_DEVICe Audio class. then I generate the code.

In all of the code, I can make changes as long as I put my code in the proper places guarded by /* USER CODE BEGIN */ / *USER CODE END */ .

There is no such mechanism for the USB classes. So if I modify or add a function, then later on I might need to re-generate the code using the Device Configuration Tool due to a project change (say, adding a GPIO pin), but doing so will overwrite all the USB files.

My workaround is to find and copy all the USB files I modified, copy them to a safe place, generate the code, then copy back my files. It's slow and error-prone

Is there a way to force STM32CubeIDE to avoid "stomping" middleware files? After all, no matter what I change in the device itself, the USB configuration is not changed. Even a checkbox option with "do not overwrite existing USB Middleware files" would help a lot.

[TDK]

It's not possible as far as I'm aware.

[BParh.1]

Yeah I don't think there is a way, I too face the same issue and quite annoyed too :).

[fbar]

Thanks for chiming in

There are two things that endlessly annoy me with the ST tools: this one, which would be easy to solve, and the fact that none of the files in device libraries has a version number. I frequently find projects online that I want to use and modify. Unless the author has specified what version of the device libraries were used, it's a long trial and error exercise in figuring out what library version to use. Since different device library version could have significant naming changes, trying to compile a project created using STM32F4 1.24.1 using, say, 1.26.0 results in a lot of errors. I opened a Git issue on this, but was completely ignored https://github.com/STMicroelectronics/stm32_mw_usb_device/issues/2. Lack of versioning is a pretty cardinal sin, as far as I'm concerned

As soon as I have a moment, I'll try opening a Github issue for the middleware file "stomping"

[TDK]

The file stomping isn't a firmware bug in any way, it's an STM32CubeMX issue/feature.
You can try swimming against the current, but accepting the tool for what it is is probably going to be less frustrating and more fruitful.

[Pavel A.]

> none of the files in device libraries has a version number.

This has been already solved. All these libraries are on github, tagged with the version.

You can keep your copy of the library under version control (git or whatever you like), define the ST github repo as remote (read-only of course).

Then you can check if some library files changed and revert them if they are.

If you need several versions of same library, keep several tags checked out.

This assumes that projects are generated with option to link library files into the cube "repository". If you choose to make copies in your project, these files become yours - mark them as you like.

--pa

[fbar]

Please note I did say "middleware", not "firmware". Yes, I perfectly understand it's a tool limitation. And I also understand that it would be extremely simple to solve, either with a checkbox in the code generation part, or using sections of the code guarded by comments, like in every other tool

[TDK]

My point is that the issue/bug/feature is not within the open source Github repo, but within the closed-source CubeMX tool.

[fbar]

The problem is not my own version tracking, that's easy to do. It's about finding someone else's code, and being unable to know what version of the libraries they used. And I didn't propose to update every single file for each release, just increment a version number in the headers when a specific file is updated. Since they are already editing those files, adding a version number is easy. All of the PDF documents available on the ST website are versioned, btw.

It's also interesting to note that in the past, ST was actually versioning the files. Look at this file from an old project I randomly found on Github https://github.com/cnoviello/stm32-nucleof4/blob/master/stm32-nucleof4-uart/system/src/stm32f4-hal/stm32f4xx_hal_i2s.c where there is a version number in the header (V1.1.0) and the most recent version of the same file from ST repository https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_i2s.c. If the headers use a similar format, a simple script can update every single file with the right version automatically before each release

But, yes, hopefully from now on everyone will start referring to the Github files. I just noticed that recently ST added a direct link to Github from the Hal files download page (e.g.https://www.st.com/en/embedded-software/stm32cubef4.html ). Still, the STM32CubeIDE doesn't allow you to build a new project from scratch linked directly to the Github repository. At least on Windows it's not possible to do what you suggest here "This assumes that projects are generated with option to link library files into the cube "repository". If you choose to make copies in your project, these files become yours - mark them as you like." STM32CubeIDE will only populate your project with the libraries downloaded from the tool itself to your local machine. YEs, you can ask the tool to "Add necessary files as reference...", but it will not offer to link to a directory of your choice. Clearly you can do it after the fact, but STM32CubeIDE is pretty hard to customize (at least for me, there might be a way to do so)

[Pavel A.]

>  Clearly you can do it after the fact, but STM32CubeIDE is pretty hard to customize (at least for me, there might be a way to do so)

Yes this is what I do for "serious" multi-user projects. Invented a system that works nicely on Windows 10 and Linux.

It requires some tedious preparation but then it works for us.

Unfortunately Keil (maybe IAR too) does not support this system. At least I don't know how. Only Eclipse CDT or makefiles (make, Cmake etc).

-- pa