cancel
Showing results for 
Search instead for 
Did you mean: 

What's the worst that can happen if I assign a (quick) interrupt HIGHER prio than timer tick in FreeRTOS?

arnold_w
Senior II

What's the worst that can happen if I assign an interrupt HIGHER prio than timer tick in FreeRTOS? Can I make the microcontroller or the operating system crash? The execution time of the high prio interrupt will be less than 100 microseconds and I plan to use 1 kHz tick frequency.

5 REPLIES 5
TDK
Guru

If that function doesn't touch anything important or shared, and if you have sufficient stack size, it should be invisible to the rest of the system.

https://forums.freertos.org/t/systick-priority-vs-all-cortex-m-priorities/9289/2

Except that it will introduce some jitter in SysTick and related things.

If you feel a post has answered your question, please click "Accept as Solution".
Pavel A.
Evangelist III

The timer of FreeRTOS (usually the systick) can, and often has lower priority than other interrupts.

There are also "quick" interrupts with priorities above configMAX_SYSCALL_INTERRUPT_PRIORITY. These interrupts are not blocked by RTOS activity.

If you also want the ST "HAL" timer for the HAL library, you choose a normal timer (TIMx), give it a high priority and handle it as a "quick" interrupt.

> Can I make the microcontroller or the operating system crash?

Yes, always. Be careful.

Yeah, both RTEMS and FreeRTOS need the tick timer to have the lowest priority in the system (if you look deep enough in the docs).

I believe the idea is, when a tick interrupt happens, it doesn't merely increment the tick count, the ISR also goes through the task switch negotiations.

You'll have to figure out what weirdness happens when one of your ISRs gets interrupted by the tick ISR and a task switch happens. It depends.

I'm concerned about the oppsite, what will happen if the RTOS is in the middle of switching context from one thread to another and my high priority interrupt all of a sudden happens.

Disregarding the CPU time, as long as the highest priority ISR does not access the RTOS API or your own hand-rolled semaphores/mutexes/etc., you should be OK. I've had to do this a couple times.

FWIW, the ISR tracing functionality of your favorite IDE is your best friend right now. If you don't have one built in, use the SWO and a couple ITM channels; one for the RTOS task swap and one for your ISR. You can watch it happen and analyze the bananas out of it to convince yourself it's cool.