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]

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.

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