STM32CubeMX2 FreeRTOS Task Implementation Conflicts With Code Regeneration

[MainForm]

Environment

• Board: NUCLEO-C562RE
• MCU: STM32C562RET6
• STM32CubeMX2: [your version]
• Project type: CMake
• Middleware: FreeRTOS configured through STM32CubeMX2

Problem

When a FreeRTOS task is configured in STM32CubeMX2, the task creation code and task entry function are generated in:

generated/middleware/freertos/mx_freertos_app.c

The official ST tutorial for using FreeRTOS with STM32CubeMX2 also shows application logic being implemented directly inside the generated task function:

https://community.st.com/stm32-mcus-60/how-to-use-freertos-with-stm32cubemx2-161926

However, after modifying the generated task function and running IDE Project Generation again, STM32CubeMX2 detects mx_freertos_app.c as an externally modified generated file and reports a conflict.

The original file can be preserved as a backup when "Overwrite with backup" is selected, so the application code is not silently lost.

However, this means that normal project regeneration requires conflict handling and potentially manual merging whenever the generated FreeRTOS task file has been modified.

How to Reproduce

1. Create a project for NUCLEO-C562RE.
2. Enable FreeRTOS in STM32CubeMX2.
3. Add a FreeRTOS task using the CubeMX2 task configuration.
4. Generate the project.
5. Add application code to the generated task function in:

generated/middleware/freertos/mx_freertos_app.c

6. Change another CubeMX2 configuration, such as a GPIO or peripheral setting.
7. Generate the project again.
8. STM32CubeMX2 reports a conflict for mx_freertos_app.c.

Occurrence

In my test, this is reproducible whenever mx_freertos_app.c has been modified and the project is generated again.

Expected Behavior / Suggestion

I would expect STM32CubeMX2 to provide an option to separate the generated FreeRTOS task configuration from the user task implementation.

For example, it would be useful to provide a "Weak" or "External" option for each task entry function.

With a Weak option, CubeMX2 could generate a default weak task implementation:

__WEAK void LedTask(void *argument)
{
    for (;;)
    {
    }
}

The user could then override the task implementation from an application-owned source file.

Alternatively, an External option could make CubeMX2 generate only the declaration and task creation code:

extern void LedTask(void *argument);

The actual task implementation could then be placed in a separate user-owned source file.

This would allow STM32CubeMX2 to continue managing:

• Task name
• Priority
• Stack size
• Task creation
• Queues
• Semaphores
• Mutexes
• FreeRTOS configuration

while keeping the actual application logic outside generated files.

This would avoid modifying mx_freertos_app.c directly and therefore avoid regeneration conflicts.

Ideally, this could be selectable per task, similar to the Weak / External task implementation workflow available in the previous STM32CubeMX.