configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOS - Step-by-Step Execution

Concept Flow - configMAX_SYSCALL_INTERRUPT_PRIORITY

Start

↓

Set configMAX_SYSCALL_INTERRUPT_PRIORITY

↓

Interrupt occurs

↓

Check interrupt priority

↓

Priority <= configMAX_SYSCALL_INTERRUPT_PRIORITY?

↓

Allow ISR to call FreeRTOS APIs

↓

ISR cannot call FreeRTOS APIs

↓

Continue execution

This flow shows how FreeRTOS uses configMAX_SYSCALL_INTERRUPT_PRIORITY to decide if an interrupt can safely call FreeRTOS functions.

Execution Sample

FreeRTOS

#define configMAX_SYSCALL_INTERRUPT_PRIORITY 5
void ISR_Handler(void) {
  if (interrupt_priority <= configMAX_SYSCALL_INTERRUPT_PRIORITY) {
    vTaskNotifyGiveFromISR(taskHandle, &xHigherPriorityTaskWoken);
  }
}

This code checks if the interrupt priority is allowed to call FreeRTOS API inside an ISR.

Execution Table

Step	Interrupt Priority	Condition (priority <= configMAX_SYSCALL_INTERRUPT_PRIORITY)	Action	Result
1	7	7 <= 5 (False)	Do NOT call FreeRTOS API	API call skipped
2	5	5 <= 5 (True)	Call FreeRTOS API from ISR	API called safely
3	3	3 <= 5 (True)	Call FreeRTOS API from ISR	API called safely
4	-	-	-	Execution continues

💡 Execution stops checking when interrupt priority is higher than configMAX_SYSCALL_INTERRUPT_PRIORITY, disallowing FreeRTOS API calls.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
interrupt_priority	-	7	5	3	-
API_call_allowed	False	False	True	True	-

Key Moments - 2 Insights

Why can't interrupts with priority higher than configMAX_SYSCALL_INTERRUPT_PRIORITY call FreeRTOS APIs?

Because FreeRTOS disables interrupts at or below configMAX_SYSCALL_INTERRUPT_PRIORITY to protect critical sections. Interrupts with higher priority run without this protection and calling FreeRTOS APIs could cause data corruption. See execution_table rows 1 and 4.

What happens if configMAX_SYSCALL_INTERRUPT_PRIORITY is set too low?

More interrupts can call FreeRTOS APIs safely, but this reduces system responsiveness because more interrupts are masked during critical sections. See execution_table rows 2 and 3.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the interrupt NOT call the FreeRTOS API?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Check the 'Action' column in execution_table for step 1.

According to variable_tracker, what is the value of API_call_allowed after step 2?

A False

B Undefined

C True

D Error

💡 Hint

Look at the 'API_call_allowed' row under 'After Step 2' in variable_tracker.

If configMAX_SYSCALL_INTERRUPT_PRIORITY was set to 3, which interrupt priority from the table would be allowed to call FreeRTOS APIs?

A 5 and 7

B 3 and 5

C Only 3

D All priorities

💡 Hint

Compare interrupt priorities to configMAX_SYSCALL_INTERRUPT_PRIORITY in execution_table.

Concept Snapshot

#define configMAX_SYSCALL_INTERRUPT_PRIORITY <value>
- Sets max interrupt priority that can safely call FreeRTOS APIs
- Interrupts with priority <= this value can use FreeRTOS API in ISR
- Higher priority interrupts must NOT call FreeRTOS API
- Protects kernel critical sections from unsafe ISR calls

Full Transcript

configMAX_SYSCALL_INTERRUPT_PRIORITY is a FreeRTOS setting that controls which interrupt priorities can safely call FreeRTOS API functions from an ISR. When an interrupt occurs, its priority is compared to this setting. If the priority is less than or equal to configMAX_SYSCALL_INTERRUPT_PRIORITY, the ISR can call FreeRTOS APIs safely. If the priority is higher, the ISR must not call these APIs to avoid corrupting kernel data. This protects critical sections where FreeRTOS disables interrupts up to this priority level. Setting this value too high reduces system responsiveness, while setting it too low restricts which ISRs can interact with FreeRTOS. The execution table shows examples of priorities and whether API calls are allowed. The variable tracker shows how interrupt_priority and API_call_allowed change step by step. Understanding this helps write safe ISRs in FreeRTOS.