CubeMX not regenerating/updating middleware files

[Pierre-François]

Hello,

I am upgrading a software from an existing project for (f7 mcu). Software is generated by an old version of stm32CubeMX installed in 2018 (never updated) (firmware version V1.14.0 ), and is using some middlewares, like FATFS. However I noticed that on each code generation, the files of the middleware folder are not getting updated.

Theferore I would greatly appreciate any help to answer the following :

-Why are those files not getting updated ? Is there a parameter somewhere in CubeMX that handles an eventual activation of the middleware files generation ?

-I plan to bring the project on modern tools (up to date stm32cubeIDE), will I be able to choose if the middlewares get generated ? Will a 2018/2019 version of a file like ff.c still work in a more recent environment ?

Kind reguards,

PF.

[Ghofrane GSOURI]

Hello @Pierre-François 

First let me thank you for posting.

Could you please share your IOC in order to push further the investigation.

I will be waiting for your feedback.

THX

Ghofrane

[Pierre-François]

Hello @Ghofrane GSOURI 

Thank you for your immediate reply.

I will not be able to share any file unfortunately. I can provide any specific parameter of the ioc file that you need me to check.

Sorry for this inconvenience

[Ghofrane GSOURI]

Hello @Pierre-François 

I would appreciate it if you could give me the version of CubeMX you mentioned that has been installed since 2018 (without any updates) (firmware version V1.14.0), and the version you desire to use now.

THX

Ghofrane

[Pierre-François]

Version used by the current project : 5.0.1 (Win10)
Version of stm32cubeIDE to be used : 1.13.2 (Win11)
Thank you

Edit: In stm32cubeIDE 1.13.2 the version of cubeMX used is  6.9.2.202309101412 if I may add

[Ghofrane GSOURI]

Hello @Pierre-François 

Migrating an IOC file from an older version of STM32CubeMX (5.0.1) to a newer version (6.9.2),across multiple major versions, especially with a gap as significant as 23 versions can indeed lead to configuration issues.

Before making any changes, ensure you have a backup of your original .ioc file. This will allow you to revert if necessary.

Since you encounter issues with direct migration, using an incremental approach can help mitigate the issue .Consider migrating first to an intermediate version from 5.0.1 to 5.4.0 , then from 5.4.0 to 6.0.0, before moving to 6.x versions, repeat this process for each major version (6.0.0 → 6.4.0 → 6.9.2).

Finally review all configurations carefully, as some settings may not translate correctly due to significant changes in the software architecture between versions.

BR,

Ghofrane

[Pierre-François]

Thank you for your help on the migration, I will make sure to follow these steps.

About the more immediate problem of the middleware files, like FATFS, not getting updated with code generation, could you tell me more about it ? I would like to know if it's possible to toggle it somewhere in the MX settings. Depending on how the migration goes, it could not be a problem if they are spared from the generation but I would like to be sure I can control it.

Reguards,

PF

[Ghofrane GSOURI]

Hello @Pierre-François 

If the middleware options were not enabled in the project configuration after migration , the corresponding files would not be generated. You should check the middleware settings in the CubeMX interface to ensure that all required middleware components (like FATFS) are enabled. After confirming that all necessary middleware is selected, regenerate the code. This should prompt CubeMX to update any outdated files.

[Pierre-François]

In my current workspace (old MX version), all the required middleware are fully enabled (green tick in the MX interface) but still the files are not updated upon generation, that is the problem. I would like to solve it if possible before considering the migration.

Reguards,

PF

[Ghofrane GSOURI]

Hello @Pierre-François 

When migrating projects to a newer version of STM32CubeMX, the tool often attempts to automatically update middleware settings based on the new version's capabilities and available components. This means that any required middleware updates should ideally occur during the migration process.