2026-04-07 2:07 AM
Hello,
I generated a project using STM32CubeMX2 for Nucleo-C5A3ZG and I imported the project using the 'STM32CubeMX2 Project' option into STM32CubeIDE. I can compile and link the code without any issues however I noticed that there is only one build configuration (debug_GCC_NUCLEO-C5A3ZG for my project). Can STM32CubeMX2 also create a release build configuration?
My second related question what is the best way to add compile flags? I managed to add a -DDEBUG flag to the flags.cmake file and it works fine. Is this the right way to do it? Would project regeneration be troubled by this change?
Finally, if I opted in for 'Assert checks on function parameters' and 'Assert checks on module state' in STM32CubeMX2 HAL System Init is there a way to only have this functionality enabled only for a debug build?
Thank you,
Gil
Solved! Go to Solution.
2026-04-13 2:54 AM
Thank you for your detailed feedback and for sharing the solution you implemented. It is good to hear that the approach works as expected in your current setup.
Regarding your remarks:
1. Add a Release build configuration in CMake when the code is generated
An internal ticket has already been submitted for this request: CDM0061318. I will keep you posted.
2. Define the DEBUG flag for the debug version
I have submitted an internal ticket for this enhancement following your request: CDM0061625. I will keep you updated.
3. Use Pre_Include_Global.h to enable the two assert compile flags only if DEBUG is defined
In STM32CubeMX2, go to the Project Settings page. In the Global Services section, open HAL System Init Configuration. There, you will find the following options:
By enabling these options, STM32CubeMX2 generates the following definitions in Pre_Include_Global.h:
#define USE_ASSERT_DBG_PARAM#define USE_ASSERT_DBG_STATEPlease do not hesitate to contact us if you need any further assistance or have any questions.
Regards,
Sara.
2026-04-07 3:39 AM
Hi @gil_dobjanschi,
Thanks a lot for your feedback and welcome to the ST Community!
At the moment, the release build configuration cannot be added via the STM32CubeMX GUI, but it is possible using the CLI.
For example, you can use a command similar to:
cube mx ide-project generate -p ./test.ioc2 --build-target .release_IAR+NUCLEO-C562RE --destination test_ewarm --format EWARM --source include-packs-from-local --force
Please check @MorkBeck reply in this thread: “STM32CubeMX2 + NUCLEO-C562RE - you need AI?” — it contains additional details and context that may be helpful.
Please let me know if you need any further assistance.
Regards,
Sara
2026-04-07 4:34 AM
Thank you for the reply Sara!
If I add the release configuration how can I handle the assert defines selectively in the debug and release builds (i.e. enable in debug build and disable in release build). It seems that STM32CubeMX2 is generating the Pre_Include_Global.h file where the two assert defines exist:
#define USE_ASSERT_DBG_PARAM
#define USE_ASSERT_DBG_STATE
It then uses the include file in STM32_HAL_Driver_codegen.cmake like this:
# Include Pre_Include_Global.h globally if needed
if(CMSIS_Tcompiler STREQUAL "IAR")
target_compile_options(generated_STMicroelectronics_stm32c5xx_hal_drivers_0_0_1 INTERFACE "SHELL:--preinclude $<QUOTE>${CMAKE_CURRENT_LIST_DIR}/Pre_Include_Global.h$<QUOTE>")
else()
target_compile_options(generated_STMicroelectronics_stm32c5xx_hal_drivers_0_0_1 INTERFACE "SHELL:-include $<QUOTE>${CMAKE_CURRENT_LIST_DIR}/Pre_Include_Global.h$<QUOTE>")
endif()
I guess in the release build these lines should not exist. I tried that but the code does not compile:
/Documents/GitHub/LED_Blink/LED_Blink_cmake/generated/hal/mx_rcc.c: In function 'mx_rcc_init':
/Documents/GitHub/LED_Blink/LED_Blink_cmake/generated/hal/mx_rcc.c:46:7: error: implicit declaration of function 'HAL_RCC_HSE_Enable'; did you mean 'HAL_RCC_LSI_Enable'? [-Wimplicit-function-declaration]
46 | if (HAL_RCC_HSE_Enable(HAL_RCC_HSE_ON) != HAL_OK)
| ^~~~~~~~~~~~~~~~~~
| HAL_RCC_LSI_Enable
/Documents/GitHub/LED_Blink/LED_Blink_cmake/generated/hal/mx_rcc.c:46:26: error: 'HAL_RCC_HSE_ON' undeclared (first use in this function)
46 | if (HAL_RCC_HSE_Enable(HAL_RCC_HSE_ON) != HAL_OK)
| ^~~~~~~~~~~~~~
Any ideas how I can proceed?
Thanks again,
Gil
2026-04-08 6:41 AM
Hi @gil_dobjanschi,
Could you please try the following steps and let us know how it goes?
Keep the pre-include mechanism and make only the assert macros configuration-specific. The cleanest version is to move the two assert defines out of the generated header and add them as Debug-only compile definitions:
target_compile_definitions(
generated_STMicroelectronics_stm32c5xx_hal_drivers_0_0_1
INTERFACE
$<$<CONFIG:Debug>:USE_ASSERT_DBG_PARAM>
$<$<CONFIG:Debug>:USE_ASSERT_DBG_STATE>
)
Then, keep the existing global -include / --preinclude logic unchanged.
If you must keep the defines inside the pre-include header, then the header itself should be conditional instead of being removed from Release. For example:
#if defined(DEBUG)
#define USE_ASSERT_DBG_PARAM
#define USE_ASSERT_DBG_STATE
#endif
And in CMake make sure DEBUG is only set for Debug builds, for example:
target_compile_definitions(your_app_target PRIVATE
$<$<CONFIG:Debug>:DEBUG>
$<$<CONFIG:Release>:NDEBUG>
)
Best regards,
Pape
2026-04-08 10:27 AM
Hi @PapeLibasse,
Thank you for your reply!
I came up with a solution just before I received your reply. It is similar to the second option you outlined in your reply.
In the Pre_Include_Global.h I did exactly what you suggested:
#if defined(DEBUG)
#define USE_ASSERT_DBG_PARAM
#define USE_ASSERT_DBG_STATE
#endif
Then in the flags.cmake for for debug_GCC_NUCLEO-C562RE I defined the DEBUG flag:
target_compile_options(${CMAKE_PROJECT_NAME} PUBLIC "SHELL:-DDEBUG -g3 -O0 -fdata-sections -ffunction-sections -std=gnu11 -Wall -fstack-usage --specs=nano.specs --specs=nosys.specs -Werror=implicit-function-declaration ${CC_SECURE}")
When there will be a release build configuration I will do:
target_compile_options(${CMAKE_PROJECT_NAME} PUBLIC "SHELL:-DNDEBUG -g0 -Os -fdata-sections -ffunction-sections -std=gnu11 -Wall -fstack-usage --specs=nano.specs --specs=nosys.specs -Werror=implicit-function-declaration ${CC_SECURE}")
That works fine but the solution as it stands right now is not ideal. When I regenerate the code with STM32CubeMX2 the software will notice that I changed the contents and may end up overwriting the Pre_Include_Global.h. This is not a major issue as I can add my #ifdef DEBUG back after the code is generated.
One possible solution from ST would be to update the STM32CubeMX2 to do the following:
1. Add a release build configuration in CMake when the code is generated.
2. Define the DEBUG flag for the debug version (possible in flags.cmake but it can be done with Cmake wizardry as well). Almost any application would benefit from this flag.
3. In Pre_Include_Global.h use the code above to enable the two assert compile flags only if DEBUG is defined. This way the code generator can define values/flags that apply only in the debug build configuration, only in the release build configuration or both.
These were just my 2 cents. Clever people in your team can come up with something even better.
Regards,
Gil
2026-04-13 2:54 AM
Thank you for your detailed feedback and for sharing the solution you implemented. It is good to hear that the approach works as expected in your current setup.
Regarding your remarks:
1. Add a Release build configuration in CMake when the code is generated
An internal ticket has already been submitted for this request: CDM0061318. I will keep you posted.
2. Define the DEBUG flag for the debug version
I have submitted an internal ticket for this enhancement following your request: CDM0061625. I will keep you updated.
3. Use Pre_Include_Global.h to enable the two assert compile flags only if DEBUG is defined
In STM32CubeMX2, go to the Project Settings page. In the Global Services section, open HAL System Init Configuration. There, you will find the following options:
By enabling these options, STM32CubeMX2 generates the following definitions in Pre_Include_Global.h:
#define USE_ASSERT_DBG_PARAM#define USE_ASSERT_DBG_STATEPlease do not hesitate to contact us if you need any further assistance or have any questions.
Regards,
Sara.
2026-04-13 6:31 AM
Thank you for considering my suggestions. I am looking forward to test the next release.
We as developers are happy to have your support in creating great embedded applications with the new MCUs and STM32CubeMX2.
Regards,
Gil