STM32CubeMX fixes timer interrupt priority for HAL timer if RTOS enabled?

@willcfj​ Interrupt level 0 is highest possible.

Normally, Systick uses lowest interrupt (assuming 4-preemption bits) of 15 [Higher number = Lower priority].

Read this useful post: https://www.freertos.org/RTOS-Cortex-M3-M4.html

Hope it is clear,

Tilen

Thanks Tilen: Yes, since FreeRTOS is using SysTick, it is at the lowest priority (15 for me). That part is OK. The problem I'm running into is the timer I chose for the ST HAL (TIM7 in my case) is being forced to level 0 (highest) by CubeMX and not changable. I need another interrupt to be higher priority than the HAL and CubeMX won't let me do this. The tie-in with FreeRTOS is it only forces the HAL timer to level 0 if I enable FreeRTOS.

I have gathered a lot of links on FreeRTOS, but not seen that one yet. That was quite helpful on understanding the configMAX_SYSCALL_INTERRUPT_PRIORITY variable. I was having trouble understanding its significance.

Just checking back on this. I plan on over-writing the CubeMX-generated code for the timer tick but really wondering if there is a reason it is forcing this.

Always first assume your code is in error before others! :)

will

Hi @willcfj​ ,

I need your ioc file please.

Best Regrads,

Wael

Just pinging again on this issue. I can't see any explanation other than a CubeMX bug and will find a way to override it at the point where it starts to create issues for my project.

will

Hello @willcfj​ 

- FreeRTOS always uses Systick as its time base

o So there are priority settings specific to Systick (note: we are talking about the SystickHandler function behind this)

- The fact that the SYS timebase is changed to set a timer, seems to require a prio setting for this timer

o But also one for systick (because FreeRTOS will always use systick for its time base)

What we fix on the stm32cubeMx side, as timebase, is the one of the IP SYS

- By default, SYS shares as timebase, Freertos' timebase, "systick".

o and it's not the healthiest setting (hence the pop-up when generating the code, which recommends choosing a timer)

- We can, therefore, set, aside stm32cubeMx, a timer to have a timebase specific to our world "HAL".

When a task has the status Running, the processor executes the task code. When a task has the status Not in progress, the task is in standby, its status having been saved. It is therefore ready to resume execution the next time the planner decides that he or she should enter the Running state. When a task resumes execution, it does so from the instruction it was about to execute the last time it was in the Running state.

Best regards,

Nesrine

Hello Nesrine and thank you for the reply:

Fully understand and OK with FreeRTROS using SysTick and the priority level for SysTick that then calls the RTOS functions. That all makes sense. What I think I'm doing different is I have the RTOS running from a different timer than the HAL. The RTOS (using SysTick) is running at 100Hz and the HAL timebase (using TIM7) needs to be at 1000Hz. That in itself should be OK. From a routine called by HAL timebase interrupt, I do need to make an RTOS call. Because of that, I need to satisfy this RTOS requirement from the link above (https://www.freertos.org/RTOS-Cortex-M3-M4.html:( (about half way down)

Relevance when using the RTOS

FreeRTOS functions that end in “FromISR�? are interrupt safe, but even these functions cannot be called from interrupts that have a logical priority above the priority defined by configMAX_SYSCALL_INTERRUPT_PRIORITY (configMAX_SYSCALL_INTERRUPT_PRIORITY is defined in the FreeRTOSConfig.h header file). Therefore, any interrupt service routine that uses an RTOS API function must have its priority manually set to a value that is numerically equal to or greater than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting. This ensures the interrupt’s logical priority is equal to or less than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting.

This seems straight forward and makes sense, but after setting up SysTick for RTOS and then setting up TIM7 for the HAL, CubeMX forces the interrupt priority for TIM7 to be 0. configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 5. That does not meet the requirement in bold above and the RTOS hangs as predicted. The "hack" I have above fixes the issue, changing the priority for TIM7 to 6.

I'm relatively new to using an RTOS, so reluctant to just dismiss it as a CubeMX bug and asking if I'm doing something wrong. It seems what CubeMX is doing is violating the RTOS's clearly documented requirements, and if so, is a bug. I believe being able to make an RTOS call from a routing running from the Hal timers is something that should be expected and allowed. Yes, if I were dumb and tried to make an RTOS call every timer tick that would be bad, but I'm not doing that! :)

Thank you for the attention. With the above fix, the code has been working fine with no observed bad side effects.

will

Piranha:

OK, I know you are a lot more expert than me, so now worried there is something I don't know. The bold sentence above says the priority must be numerically equal to or greater than LIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY, so >=5, right? My problem is CubeMX fixes the Timer ISR to interrupt priority 0. If I'm confused it is very fundamental! There are other places that say the same thing too. Another good example is UM1718 section 4.4.14, where they even show an example related to RTOS support. it says: "In this case, all the interrupt service routines (ISRs) that are calling the interrupt safe FreeRTOS APIs must have a priority lower than the priority defined in the LIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY parameter (the highest the value, the lowest the priority). The check in the corresponding checkbox guarantees that the restriction is applied." If you check the box that says this ISR makes RTOS calls, the only available priorities are >=LIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY.

Thanks in advance for your answers. RTOS programming is new to me, so trying to understand. This seems pretty fundamental and besides the conflict between CubeMX and lots of documentation, with the TIM7 priority set to 0, the RTOS hangs, but not when i override CubeMx in my source and set a priority of 6 all works fine. So even the code seems to agree with the docs.

will

Piranha:

OK, that may be the official answer, I should not be making RTOS calls from code being called by the HAL Tick ISR. I have some code from a pre-RTOS project that does some status polling based on the HAL timer tick. It is polling the status of some audio DSP code that needs to be higher priority than the timer tick as I can't afford any timer tick code to preempt the audio code.

I do see that if somewhere in code that isn't mine there is an assumption that HAL code can interrupt RTOS code, something might break. Time to think about re-factoring the code...

will