Upgrading STM32CubeIDE and TouchGFX results in loss of Middleware, CMSIS, and HAL

[wired]

I've been trying to upgrade an existing working TouchGFX application that was in STM32CubeIDE 1.7.0 and TouchGFX Designer v4.18.0. I've spent an entire day trying various ways to upgrade the project, but I keep running into undefined reference errors. My application is for an STM32F469I-DISCO board, and I have my own custom code in addition to the Designer-generated code.

I first updated CubeIDE to the latest version, 1.10.1.

For the rest of this discussion, know that I first copy my entire original project folder to a separate location each time I attempt the update.

I was able to open my project in the new IDE and build it without errors. My original project explorer window looks like this:

You can see that there is a CMSIS folder, a STM32F4xx_HAL_Driver folder, and a Middlewares folder with FreeRTOS. Each of these folders contains linked files to the source.

Next, I try to open the STM32F469I-DISCO.ioc file in CubeMX, and I am presented with the following dialog:

When I select Migrate, the process results in the loss of the previously mentioned folders, and I get this:

 

Now when I Generate Code in MX and then do a build, I get over 300 undefined references, most due to HAL_ calls. The missing folders were originally added automatically when I first created the project (I think - it's been a long time).

I have also tried updating my GUI in Designer to version 4.20, and then generating code. I get a lot of GetColorFrom24BitRGB() undefined errors when I build in the IDE and have to change all my calls to GetColorFromRGB() (a pain since I have a lot of interactions with this call in the External C++ code), but other than that, no big deal. My main problem seems to be from the loss of the folders in my project, which implies that the migration is none too friendly.

Does anyone have any suggestions as to how to accomplish a working upgrade? I'm rapidly going bald...

[ktrofimo]

Yes, stumbled on the same issue. I decided to manually recreate project structure. After making all missing project folders and linking all files to these project folders everything was compiled okay.​

[wired]

Thanks for the rapid reply! I was unsure about where the actual files are located, and if they are different for the upgraded software. When manually changing things, there is always a risk of 'fixing' it, but it does not represent what the content would be if the migration had worked correctly. I'll take a look at doing what you said, but I'm hoping someone at ST can explain why the migration causes these issues and whether it is expected.

[wired]

Just to clarify my original problem. When I Generate Code in STM32CubeMX, the CMSIS, Middlewares, and STM32F4xx_HAL_driver folders disappear, then briefly reappear, then disappear again during the code generation process.

[wired · Accepted solution]

Just to update where I'm at right now, I was able to get the missing folders to come back. This was after hours of trying different things in different orders. To the best of my weary mind's recollection, this is what worked:

1. Open the TouchGFX 4.18 project in the new 1.10.1 IDE.
2. Build project (no errors).
3. With the project open, run STM32CubeMX from the desktop, not from within the IDE.
4. Press the Generate Code button (this caused the folders in the project to disappear).
5. From within the project, double-click the .ioc file to bring up the CubeMX window.
6. Force a configuration change, e.g. by enabling WWDG and disabling it again (this is annoying, BTW - you should not have to make a change and then unmake it in order to be able to generate code. There is a GENERATE CODE button when you run it externally, there should be a button as well when it is started in the IDE). This actually brought the missing folders back.

I am still getting a lot of undefined references after updating to the 4.20 GUI however, but at least I have the necessary folders.

[wired]

With respect to the undefined references:

I have moved this project around a lot, as I performed various types of testing and attempted upgrades, etc.

It seems the project was automatically accumulating library paths from all of these other locations, versions of the project, etc. I went into the Properties of the project, and in the Paths and Symbols I selected the Library Paths tab, and deleted all of the paths except for the first path (a git pat) and the path to my current project. I rebuilt and all 52 errors disappeared.

The transition from 4.18 to 4.20 was far from seamless, at least for me.