C5 - CubeMX2/HAL2: freeRTOS timebase issues

[User_MV]

Hello @st,

I am testing the C5 with freeRTOS and I am having some issues that I like to report. I am doing it from scratch (start with MCU), so it may be a configuration issue....  I enabled freeRTOS and changed the SysTick timer to tim6.

Here is the first issue: the interrupt priority is kept at 0 by default. In CubeMX1 this is automatically set to 5 (or the configured min. freeRTOS priority).

Anyway, after changing that, the SysTick runs, so HAL_Delay() and so on works, e.g. before you start the scheduler.

Then I setup the project and CubeIDE for freeRTOS aware debugging following UM2609 with tim7 as statistics counter.

Now the SysTick timer is way to fast.

(I thought this cause by the HAL function HAL_TIM_GetClockFreq(timebase_gethandle()); (stm32c5xx_drivers/timebase/stm32_hal_timebase_tim.c line 121)) returns 48000000 instead of 144000000 when I debug it. But maybe not since reading the prescaler and the timer period returns the correct values.....)

The problem is the generated function void HAL_TIM_UpdateCallback(hal_tim_handle_t *htim) in stm32c5xx_drivers/timebase/stm32_hal_timebase_tim.c line 255, which is used when ISR callbacks are not enabled. This function is called in the general timer ISR handler HAL_TIM_IRQHandler() and because there are no timer guards for TIM6, the sysTick counter is increased by every timer event, not just the events generated by htim6.

So I guess the bug would be: timebase timer guards missing in TIMER_IRQ function when IRQ callbacks are disabled.

The third think is the location of the timebase stuff. This seems to be generated and/or might need case specific changes, so having it be located under stm32c5xx_driver/ is kind of odd in my humble opinion....

And here are some Setup Infos:

• CubeMX2 1.0.0 because 1.0.1 did not generate the main.c/h files (template pack was missing in the project settings)
• MCU: C542CCU6
• OS: MacOS
• CubeIDE: 2.1.1. (cmake base project)

[Khaled_DHIF]

Hello @User_MV ,

Thank you for reporting this and for the detailed investigation.

For the first point, with CubeMX2 the generated HAL_InitTick() is overwritten in stm32_hal_timebase_tim.c and called with tick_priority = 15, which explains why the interrupt priority no longer matches the default value you observed with CubeMX1, while still remaining correct.

For the second point, the behavior you describe is consistent with how the HAL callback mechanism works when register callback support is disabled. In that case, if you want to override the timer callback behavior with your own implementation, you should enable “Use register callback” under HAL TIM in the Common Definitions tab. Without that option enabled, the generated weak/default callback path is used, which can lead to the callback being executed in a broader context than expected.

For the third point, I believe the generated stm32_hal_timebase_tim.c file is more appropriately located under the timebase folder, since it is used to redefine HAL timekeeping functionality originally provided by the HAL drivers. Grouping these files in a dedicated and clearly named folder improves readability and keeps the clock/timebase-related customization in one place.

Kind regards,

DHIF Khaled

[User_MV]

Hello @Khaled_DHIF,

Regarding your response to the first point: My main point is, that CubeMX2 is not (yet?) adjusting the ISR priorities to the freeRTOS configuration. The timer was just a real world example.

Regarding your response to the second point: I get that this is the expected behavior. My point was/is that the via CubeMX2 generated code is not functioning as expected. CubeMX2 generated the HAL_TIM_UpdateCallback() instead of generating the specific Timer_N ISR callback for the timebase. Which is fine but then imho there should be guards, like in the CubeMX1 HAL_xxx_MspInit functions.
Something like:  

if (tim_baseHandle->Instance==TIM2){ } ....

I assume having multiple timers is some what common, so having the generated code break because of that would be very, let`s say unfortunate .... imho...

Regarding your response to the third point: The timebase folder was not the "problem". I would expect everything in the stm32c5xx_driver/ folder to be static. Especially if there is already a clearly label folder "generated". 
So I guess my point was, that the assumed clear separation between static and generated code is violated by the timebase stuff. 

If one of the design goals of CubeMX2 and HAL2 was such a clear separation then you might want to raise the issue with the development team if not, then don't. 

[Khaled_DHIF]

Hello @User_MV,

Thank you for the clarification.

For the first point, I can see your concern. CubeMX2 does delegate part of the interrupt-priority handling to the FreeRTOS configuration, as indicated in the UI under NVIC in Peripherals tab, so the generated setup should be reviewed in that context.

For the second point, the timebase callback is correctly bound to the selected timer instance through the timebase_gethandle() macro, which returns the proper TIM handle used by the timebase implementation. Because of that, the generated code already targets the intended timer, and the additional instance guards you mentioned are not required in this flow.

For the last point, the timebase file is part of a series-specific template maintained by ST and adapted for the selected HAL timebase source, rather than being a direct reflection of a peripheral configuration from the CubeMX2 UI. This is different from the usual peripheral code generation flow, where the selected configuration is mapped directly into the generated project files.

I hope this helps clarify the distinction.

If you would like a broader overview of HAL2 and the CubeMX2 generation model, you may find the following documentation helpful: https://dev.st.com/stm32cube-docs/embedded-software/2.0.0/en/index.html

Best regards,
DHIF Khaled