Upgrading STM32Cube FW_H7 firmware breaks build for Riverdi RVT70 project

[CTapp.1]

I have used the 70STM32H7 template in TouchGFX Designer 4.26.1 to create a project for a Riverdi RVT70 board.

I've created a basic start screen, generated code and built it using CubeIDE 2.1.0.

The code loads onto the target and runs as expected.

If I open the project's .ioc file, I am told that the project uses V1.12.1 of the STM32Cube FW_H7 and V.13.0 is available. Upgrading to this version, saving and regenerating the code results in the project failing to build:

In file included from ../../../CM7/USB_HOST/Target/usbh_conf.h:98,
 from ../../../Middlewares/ST/STM32_USB_Host_Library/Core/Inc/usbh_core.h:27,
 from ../../../Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Inc/usbh_msc_bot.h:28,
 from C:/TouchGFXProjects/GFX/Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Src/usbh_msc_bot.c:27:
../../../Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2/cmsis_os.h:32:10: fatal error: cmsis_os2.h: No such file or directory
 32 | #include "cmsis_os2.h"

This can be fixed by adding a new include path (C and C++):

../../../Drivers/CMSIS/RTOS2/Include

 That gets the build to run a bit further, but there is then an error in freertos.c:

C:/TouchGFXProjects/GFX/CM7/Core/Src/freertos.c:109:6: error: conflicting types for 'vApplicationStackOverflowHook'; have 'void(struct tskTaskControlBlock *, signed char *)'
 109 | void vApplicationStackOverflowHook(xTaskHandle xTask, signed char *pcTaskName)
 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:/TouchGFXProjects/GFX/CM7/Core/Src/freertos.c:91:6: note: previous declaration of 'vApplicationStackOverflowHook' with type 'void(struct tskTaskControlBlock *, char *)'
 91 | void vApplicationStackOverflowHook(xTaskHandle xTask, char *pcTaskName);
 | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That can be fixed by removing 'signed' from the function's definition.

Is this down to issues with the V1.13.0 firmware, or are "glitches" to be expected when accepting the offer to "migrate"?

[Pavel A.]

Knowing that a new version of the library is available does not mean that the user must immediately update. Every bit of change is a potential bomb that can destroy existing code.  If you don't feel like porting the code to  the new STM32Cube FW_H7 library version, resist the knee reflex and stay with the current ( = old) version. Previous versions of the STM32Cube FW_H7 can be found on the ST web site (as zip files) or on github (slightly more complicated to install). Several library versions can be installed side by side.

Note that for STM32H7, FreeRTOS is part of the CubeH7 library so updates with it. For other/newer STM32 families FreeRTOS is a separate package.

[CTapp.1]

---

@Pavel A. wrote:

Knowing that a new version of the library is available does not mean that the user must immediately update. Every bit of change is a potential bomb that can destroy existing code.

True, but I would expect an updated HAL to compile cleanly if there are no API changes.

The problem with not upgrading is I get asked to upgrade every time I open the .ioc. Seems like there's no way to say "I want to stick with this version"?

[Pavel A.]

In the .ioc file, find the following line and change to false. Sorry I don't remember how to do this in the GUI.

ProjectManager.AskForMigrate=true

 

[Osman SOYKURT]

Hello @CTapp.1 ,

You're right about the migration, the thing is Riverdi doesn't update their projects everytime a new version of the firmware, or STM32CubeMX or TouchGFX also updates. But as @Pavel A. suggested you're free not to accept the migration and keep using the old firmware. I invite you to select his answer as solution if that helped you :)

[CTapp.1]

Done.

I've been in contact with them directly and now have an updated template.