CubeMX & FreeRTOS -> Using SysTick

[vincenthamp9]

Posted on March 31, 2016 at 12:11

Hello

I'd just like to know why CubeMX strongly recommends to use other timers besides SysTick as source? I've always thought that the SysTick timer is basically intended for use with an embedded OS?

Thanks

[Walid FTITI_O]

Posted on March 31, 2016 at 12:46

Hi see.juan,

As mentioned is the UM1718 ?STM32CubeM user manual:

?

By default, the STM32Cube HAL is built around a unique timebase source which is the ARM-Cortex system timer (SysTick).

However, HAL-timebase related functions are defined as weak so that they can be overloaded to use another hardware timebase source. This is strongly recommended when the application uses an

RTOS, since this middleware has full control on the SysTick configuration (tick and priority) and most RTOSs force the SysTick priority to be the lowest.

Using the SysTick remains acceptable if the application respects the HAL programming model, that is, does not perform any call to HAL timebase services within an Interrupt Service Request context (no dead lock issue).

To change the HAL timebase source, go to the SYS peripheral in the IP tree pane and select a clock among the available clock sources: SysTick, TIM1, TIM2,...?

So you can select a HAL timebase source (STM32F407 example) as follow: ( note that the selected timer will be grayed and can no longer be selected)

-Hannibal-

[Schmesterle]

Facing the same problem at the moment here.

The readings from UM1718 sounds to me that the hal is using the systick and the rtos shall use another timesource? is this correct or is it that the hal is using the same timesource as the rtos does?

[vincenthamp9]

Posted on March 31, 2016 at 12:55

Thank you very much!

I'd recommend to add a hint to the pop-up warning within CubeMX, instead of just flashing the warning without any further information. Also I find the message to be slightly misleading.

''It is strongly recommended to use a timebase source other than the Systick when FreeRTOS is used. The timebase source can be changed from Pinout tab under SYS.''

That reads as if the timebase source for FreeRTOS gets changed by that option in the SYS tab, not the timebase for HAL.

[Walid FTITI_O]

Posted on March 31, 2016 at 13:12

Hi Vinci,

You recommendation is appreciated and I will communicate it internally.

-Hannibal-

[tito]

Posted on September 23, 2016 at 11:17

Hi,

Thanks for the explaination and reference to the user manual, it is greatly appreciated.

I still have one question though : what timer should I select? In the UM, there are screenshots showing TIM2 selected. But is there any reason to select one time over the other for a very simple code?

Thanks for your help

[Walid FTITI_O]

Posted on September 23, 2016 at 12:49

Hi de_wolf.christophe,

There is no restriction . Any timer can be used in addition to systick possibility.

have a good day.

-Hannibal-

[Walter Lucetti]

Posted on October 23, 2016 at 20:29

Hello,

if I follow the recommendation and I use one of the timers, the firmware freezes during the initialization phase of the system clock in ''HAL_Init->HAL_InitTick''

If I use the SysTick I have no problem.

Walter

[VTOL_Aviations]

Hey @Community member​ 

I've faced the same problem. But if I use the SysTick, the code is not working at all. I'm just blinking the LEDs in two different tasks.

If you have any solution for this, please do mention.

Aditya

[JGENT]

Hello,

I have same kind of concern.  Is there an application note to explain how to manage the different Timer. I read the doc and my understanding is thta a high priority timer is needed for the HAL and a low priority is needed for the RTOS / systick.  I follow the doc and used TIM6 for the HAL timer, it works fine , I have to manually add the ​call the HAL_TIM_IRQHANDLER

void TIM6_DAC_IRQHandler(void)

{

 /* USER CODE BEGIN TIM6_DAC_IRQn 0 */

 /* USER CODE END TIM6_DAC_IRQn 0 */

 HAL_TIM_IRQHandler(&htim6);

 /* USER CODE BEGIN TIM6_DAC_IRQn 1 */

 /* USER CODE END TIM6_DAC_IRQn 1 */

}

But then at that stage ,it seems that no code is generated to perform initialization of the RTOS tick , CubeMX generates the file stm32h7xx_hal_timebase.c which replace the weak function use to init the hal_systick.  So who is supposezd to initialized the systick now ?

CubeMX does not seem to generate code for this.

Its seems to have several way to use the timer with FreeRTOS , I ask several developper working with CubeMX but known has been able to give me a clear explanation of what we are supposed to do , so evetbody tring to implement its own solution .

Hope someone can realy exaplin how its supposed to work.

 Jean-Marc

[Piranha]

> So who is supposezd to initialized the systick now ?

FreeRTOS. At least the normal unmodified FreeRTOS takes care of SysTick on it's own.

> I ask several developper working with CubeMX but known has been able to give me a clear explanation

For click-kiddies it's not modern to stress the brain - exactly like in a HAL/CubeMX team... ;)

[mcizmeci]

Can anyone find the solution to this problem? I have the same problem, please help me.

The loop enters one when a timer other than Systick is selected. It keeps rebooting. But when timebase source is selected, systick without any problem. But I have to use freertos and I need a timer. The processor I use is stm32f746vgt6