Code generated by STM32CubeMX sets the HAL timebase ISR priority incorrectly when using FreeRTOS? Is it really necessary to have a separate timebase?

[RBack.1]

My STM32F745VET project was built in MX v6.3.0 and uses FreeRTOS. When SysTick is dedicated to the RTOS I get the following message when I try to build code:

"When RTOS is used, it is strongly recommended to use a HAL timebase source other than the Systick. The HAL timebase source can be changed from the Pinout tab under SYS"

I arbitrarily picked TIM14 for the timebase source and see it has priority 15 in MX, the same as the FreeRTOS tick ISR.

The code that MX generates does set the TIM14 ISR priority to 15 in HAL_Init(), but subsequently sets it to "16" in SystemClock_Config() when it calls HAL_RCC_ClockConfig(). This 16 gets truncated to 0 and this ISR interrupts my critical sections of code.

I believe this is just a bug in the code generated by MX? I manually fixed it but that solution is not optimal and it'd be better to simply not have this ISR. What risk makes MX "strongly recommend" having a separate HAL timebase?

[TDK · Accepted solution]

Yes, it's a bug:

https://community.st.com/s/question/0D73W000001MjAs/detail?s1oid=00Db0000000YtG6&s1nid=0DB0X000000DYbd&emkind=chatterCommentNotification&s1uid=0050X000007vmts&emtm=1636554989654&fromEmail=1&s1ext=0

> What risk makes MX "strongly recommend" having a separate HAL timebase?

See response by Dave Nadler in this thread:

https://community.st.com/s/question/0D50X0000A4nQxpSQE/when-freertos-is-used-it-is-strongly-recommended-to-use-a-hal-time-base-source-other-than-the-systick-

[RBack.1]

Thank you for your reply and I apologize for not adequately searching existing threads before submitting a duplicate question.

I understand what Dave Nadler says in this response:

> If HAL also uses systick, it slows down FreeRTOS preemption, increases potential interrupt latency, etc. Better that only FreeRTOS uses systick: its faster & cleaner. Look at generated code for both cases and this should be clear.

It seems like the behavior wouldn't be any better by giving the HAL timebase its own interrupt, however. It's true that the RTOS tick ISR will be delayed by the HAL code when returning to the task it has selected to run, but using two ISRs the task is going to have to wait for the HAL timer interrupt latency in addtion to the code it calls.

[TDK]

The search functionality here is pretty bad. Even if you did look, might not have found it. I use Google and restrict results to community.st.com which works fairly well.

I tend to agree with your assessment on the second point. However, I'm not an expert with FreeRTOS. Perhaps @Dave Nadler​ could explain/elaborate if he's around.

[Pavel A.]

As Mr. Nadler noted there, FreeRTOS needs the timer interrupt (either periodic or not) for task preemption.

This interrupt has low priority by design - normally lower than interrupts from most devices. The timer thread runs delayed events (like Linux bottom halves or Windows DPCs).

On the other hand, the ST HAL does not need the timer interrupt at all.

In earlier HAL versions there was a [weak] callback, to let the user do something on every tick.

Later it was removed, all that is left now is HAL_GetTick which returns monotonic time.

This can be done with a free running 32-bit timer. Then questions about the HAL timer priority or interference become mute.

But if one wants an interrupt, they are free to do so and choose any priority. It does not have to be the highest (0).

-- pa

[Cave Salamander]

I can not open proposed links (access denied).

This information looks helpful:

FreeRTOS setup on the Nucleo - System Timer

https://dds-demonstrators.readthedocs.io/en/latest/Teams/2.Demonstra-Tors/7.NucleoDDS/DDSFreeRTOS.html#system-timer

[dana_sch]

Link is dead. Do you have an archived copy?