FreeRTOS interrupt priority restrictions - Step-by-Step Execution

Concept Flow - FreeRTOS interrupt priority restrictions

Interrupt occurs

↓

Check interrupt priority

↓

Call ISR

↓

Return from ISR

When an interrupt happens, FreeRTOS checks its priority. If the priority is allowed, the ISR runs normally. If too high, the ISR must follow restrictions to keep the system safe.

Execution Sample

FreeRTOS

void ISR_Handler(void) {
  if (interrupt_priority <= configMAX_SYSCALL_INTERRUPT_PRIORITY) {
    // Safe to call FreeRTOS API
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xSemaphoreGiveFromISR(&xSemaphore, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
  } else {
    // Cannot call FreeRTOS API
    // Handle interrupt without FreeRTOS calls
  }
}

This ISR checks if its priority is allowed to call FreeRTOS API functions safely, otherwise it avoids those calls.

Execution Table

Step	Interrupt Priority	Condition	Action	FreeRTOS API Call Allowed	Output
1	12	12 >= configMAX_SYSCALL_INTERRUPT_PRIORITY (10)?	No	No	Do not call FreeRTOS API
2	5	5 >= configMAX_SYSCALL_INTERRUPT_PRIORITY (10)?	Yes	Yes	Call FreeRTOS API safely
3	5	ISR calls xSemaphoreGiveFromISR	Allowed	Yes	Semaphore given, possibly yield
4	12	ISR tries to call FreeRTOS API	Not allowed	No	Undefined behavior avoided by restriction
5	-	ISR returns	-	-	Scheduler may run if needed

💡 Execution stops after ISR returns and scheduler runs if a context switch is needed.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
interrupt_priority	N/A	12	5	5	12	N/A
xHigherPriorityTaskWoken	pdFALSE	pdFALSE	pdFALSE	pdTRUE or pdFALSE	pdFALSE	N/A
FreeRTOS API call allowed	N/A	No	Yes	Yes	No	N/A

Key Moments - 3 Insights

Why can't we call FreeRTOS API functions from all interrupt priorities?

Because calling FreeRTOS API from interrupts with priority higher than configMAX_SYSCALL_INTERRUPT_PRIORITY can cause system instability. See execution_table rows 1 and 4 where API calls are disallowed.

What happens if an ISR with too high priority calls FreeRTOS API anyway?

It can cause unpredictable behavior or crashes. The code must avoid such calls as shown in execution_table row 4.

How does FreeRTOS know when to switch tasks after an ISR?

The ISR sets xHigherPriorityTaskWoken to pdTRUE if a higher priority task was unblocked, then portYIELD_FROM_ISR triggers a context switch if needed (see execution_table row 3).

Visual Quiz - 3 Questions

Look at the execution_table, at step 2, what is the interrupt priority and is FreeRTOS API call allowed?

A Priority 5, API call not allowed

B Priority 5, API call allowed

C Priority 12, API call allowed

D Priority 12, API call not allowed

💡 Hint

Check execution_table row 2 for interrupt priority and API call permission.

According to variable_tracker, what is the value of xHigherPriorityTaskWoken after step 3?

A pdFALSE

B Always pdTRUE

C pdTRUE or pdFALSE

D Undefined

💡 Hint

Look at variable_tracker row for xHigherPriorityTaskWoken after step 3.

If interrupt_priority was changed to 8, how would the FreeRTOS API call allowed column change at step 1?

A It would change to Yes

B It would be undefined

C It would still be No

D It would cause a crash

💡 Hint

Compare interrupt_priority 8 with configMAX_SYSCALL_INTERRUPT_PRIORITY 10 in execution_table step 1.

Concept Snapshot

FreeRTOS interrupt priority restrictions:
- Only interrupts with priority <= configMAX_SYSCALL_INTERRUPT_PRIORITY can call FreeRTOS API.
- Higher priority interrupts must avoid FreeRTOS API calls.
- Use xHigherPriorityTaskWoken and portYIELD_FROM_ISR to request context switch.
- Violating priority rules causes instability.
- Always check priority before calling FreeRTOS API in ISR.

Full Transcript

When an interrupt happens in FreeRTOS, the system checks its priority. If the priority is less than or equal to configMAX_SYSCALL_INTERRUPT_PRIORITY, the interrupt service routine (ISR) can safely call FreeRTOS API functions like giving semaphores or notifying tasks. This is shown in the execution table where priority 5 allows API calls. If the priority is higher, like 12, the ISR must not call FreeRTOS API functions to avoid system crashes or unpredictable behavior. The variable tracker shows how the interrupt priority and the flag xHigherPriorityTaskWoken change during execution. The key moments explain why these restrictions exist and how FreeRTOS manages task switching after interrupts. The visual quiz tests understanding of priority checks and API call permissions. Remember, always keep ISR priorities and FreeRTOS API calls aligned to keep your system stable.