Hello,
I found a CubeMX database issue affecting STM32H747 dual-core projects using FreeRTOS with CMSIS-RTOS V2.
Environment
MCU: STM32H747
Cube/HAL: STM32CubeH7 1.13.x
CubeMX: 6.17
FreeRTOS: 10.6.2
Problem
Two FreeRTOS configuration parameters are not present in the MicroXplorer Configuration settings and are not retained in the internal IOC model:
configUSE_SB_COMPLETED_CALLBACK
configUSE_MINI_LIST_ITEM
Because of that, code generation can produce invalid output in FreeRTOSConfig.h such as:
#define configUSE_MINI_LIST_ITEM ( valueNotSetted )
#define configUSE_SB_COMPLETED_CALLBACK ( valueNotSetted )
This breaks the build and/or downstream FreeRTOS code.
Editing the .ioc manually does not solve it permanently, because CubeMX overwrites the .ioc on regeneration.
Adding manual defines in USER CODE blocks is only a local workaround and does not fix the root cause.
Root cause found
The issue appears to be in the CubeMX FreeRTOS mode database, not in the generated project itself.
For STM32H747, CubeMX uses a FreeRTOS mode definition named FREERTOS-v8.0.0_Cube_Modes.xml for the UI/model layer, even though the generated FreeRTOS content/template is 10.6.2.
Inside that mode file, the two missing parameters were defined with a condition using: S_CMSIS_RTOS_V2
But for H747 dual-core per-context FreeRTOS instances, they need to be context-aware like the neighboring parameters, for example: S_CMSIS_RTOS_V2$context.
Without $context, those parameters are not properly exposed or persisted for the per-core FreeRTOS instances.
Local fix that works
In the CubeMX database file db/mcu/IP/FREERTOS-v8.0.0_Cube_Modes.xml, change the condition for configUSE_SB_COMPLETED_CALLBACK from S_CMSIS_RTOS_V2 to S_CMSIS_RTOS_V2$context.
Do the same for configUSE_MINI_LIST_ITEM, again changing S_CMSIS_RTOS_V2 to S_CMSIS_RTOS_V2$context.
After this change, the issue is fixed on my side.
Additional defensive fix
To prevent broken generation even if the parameters are still missing in some cases, I also added fallback defaults in the FreeRTOS H7 template file db/templates/freertos_conf_v10_6_2_cmsis_v2.ftl.
The defaults I added were:
- valueUSE_SB_COMPLETED_CALLBACK = 0
- valueUSE_MINI_LIST_ITEM = 1
This avoids generation of valueNotSetted in FreeRTOSConfig.h.
Why this is confusing
CubeMX shows or generates FreeRTOS 10.6.2, but the bug is in the v8.0.0_Cube mode XML.
From debugging this, it looks like:
- the v8.0.0_Cube file is the CubeMX metadata and UI layer
- the 10.6.2 files are the actual generation and template layer
So the wrong behavior comes from the UI/model database, while the generated template already expects the two parameters correctly.
Expected behavior
For STM32H747 FreeRTOS CMSIS-V2 projects, CubeMX should:
- expose configUSE_SB_COMPLETED_CALLBACK
- expose configUSE_MINI_LIST_ITEM
- persist them in the internal model and IOC
- generate valid values in FreeRTOSConfig.h
Observed behavior
CubeMX omits those settings from the model/UI for H747 and can generate invalid FreeRTOSConfig.h output where configUSE_MINI_LIST_ITEM and configUSE_SB_COMPLETED_CALLBACK are set to valueNotSetted.
Request
Please fix the FreeRTOS mode database for H747 dual-core/per-context handling so these two parameters use the correct context-aware condition and are always generated with valid values.
