FreeRTOS interrupt priority restrictions - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Interrupt Priority and API Call Safety

Consider a FreeRTOS system where configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x20. An interrupt with priority 0x10 calls a FreeRTOS API function that is not safe to call from that priority level. What will most likely happen?

A The FreeRTOS kernel may behave unpredictably or crash due to priority violation.

B The system will run normally without any issues.

C The interrupt will be automatically lowered to a safe priority by FreeRTOS.

D The API call will be ignored silently by FreeRTOS.

💡 Hint

Think about what happens if an interrupt calls a FreeRTOS API function from a priority above the allowed maximum.

FreeRTOS requires that interrupts calling certain API functions must have a priority equal to or numerically higher (lower urgency) than configMAX_SYSCALL_INTERRUPT_PRIORITY. Violating this causes unpredictable behavior or crashes.

🧠 Conceptual

intermediate

Understanding configMAX_SYSCALL_INTERRUPT_PRIORITY

What does the FreeRTOS configuration constant configMAX_SYSCALL_INTERRUPT_PRIORITY control?

A It disables all interrupts above a certain priority level.

B It defines the lowest interrupt priority allowed in the system.

C It sets the highest interrupt priority from which FreeRTOS API calls can be safely made.

D It sets the priority of the FreeRTOS kernel task.

💡 Hint

Think about which interrupts can safely call FreeRTOS API functions.

configMAX_SYSCALL_INTERRUPT_PRIORITY defines the highest interrupt priority (numerically lowest) from which FreeRTOS API functions that end in "FromISR" can be called safely.

🔧 Debug

advanced

Debugging Priority Violation in ISR

A developer reports that their FreeRTOS application crashes when an ISR calls xQueueSendFromISR(). The ISR priority is set to 0x10, and configMAX_SYSCALL_INTERRUPT_PRIORITY is 0x20. What is the most likely cause?

A The ISR is missing a call to <code>portYIELD_FROM_ISR()</code> after sending to the queue.

B The queue handle passed to <code>xQueueSendFromISR()</code> is NULL.

C The FreeRTOS scheduler was not started before the ISR executed.

D The ISR priority is too high (numerically lower) and violates the maximum syscall interrupt priority restriction.

💡 Hint

Check the relationship between ISR priority and configMAX_SYSCALL_INTERRUPT_PRIORITY.

Calling FreeRTOS API functions from an ISR with priority higher than configMAX_SYSCALL_INTERRUPT_PRIORITY causes crashes or undefined behavior.

📝 Syntax

advanced

Correct Priority Setting for ISR

Which of the following correctly sets an ISR priority to be safe for calling FreeRTOS API functions if configMAX_SYSCALL_INTERRUPT_PRIORITY is 0x30?

A NVIC_SetPriority(IRQn, 0x40);

B NVIC_SetPriority(IRQn, 0x00);

C NVIC_SetPriority(IRQn, 0x10);

D NVIC_SetPriority(IRQn, 0x20);

💡 Hint

Remember that lower numerical values mean higher priority.

Interrupt priorities numerically equal or higher (less urgent) than configMAX_SYSCALL_INTERRUPT_PRIORITY are safe to call FreeRTOS API functions. 0x40 is numerically higher than 0x30, so it is safe.

🚀 Application

expert

Designing ISR Priorities with FreeRTOS Restrictions

You are designing a system with three interrupts: Timer (priority 0x10), UART (priority 0x40), and ADC (priority 0x50). configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x40. Which interrupts can safely call FreeRTOS API functions?

A Only Timer interrupt can safely call FreeRTOS API functions.

B Only UART and ADC interrupts can safely call FreeRTOS API functions.

C All three interrupts can safely call FreeRTOS API functions.

D None of the interrupts can safely call FreeRTOS API functions.

💡 Hint

Compare each interrupt priority to configMAX_SYSCALL_INTERRUPT_PRIORITY.

Only interrupts with priority numerically equal or higher (less urgent) than configMAX_SYSCALL_INTERRUPT_PRIORITY (0x40) can safely call FreeRTOS API functions. Timer (0x10) is higher priority and cannot.

Practice

1.

What does configMAX_SYSCALL_INTERRUPT_PRIORITY control in FreeRTOS?

easy

A. The maximum number of interrupts allowed

B. The lowest interrupt priority allowed in the system

C. The highest interrupt priority that can safely call FreeRTOS API functions

D. The priority of the idle task

Solution

1. Step 1: Understand FreeRTOS interrupt priority limits

   FreeRTOS restricts API calls to interrupts at or below a certain priority level to maintain system stability.

2. Step 2: Role of configMAX_SYSCALL_INTERRUPT_PRIORITY

   This configuration sets the highest interrupt priority that can safely call FreeRTOS API functions.

3. Final Answer:

   The highest interrupt priority that can safely call FreeRTOS API functions -> Option C

4. Quick Check:

   configMAX_SYSCALL_INTERRUPT_PRIORITY = highest safe ISR priority [OK]

Hint: Remember: configMAX_SYSCALL_INTERRUPT_PRIORITY limits safe ISR API calls [OK]

Common Mistakes:

• Confusing highest with lowest priority
• Thinking it limits number of interrupts
• Assuming it sets task priorities

2.

Which of the following is the correct way to define configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h?

#define configMAX_SYSCALL_INTERRUPT_PRIORITY  ( ??? )

easy

A. 0x80 // Mid-level priority

B. 0x00 // Highest priority

C. 0xFF // Lowest priority

D. "5" // Priority as string

Solution

1. Step 1: Understand priority values in FreeRTOS

   Lower numeric values represent higher priorities; 0x00 is highest, 0xFF is lowest.

2. Step 2: Correct format for configMAX_SYSCALL_INTERRUPT_PRIORITY

   This macro must be a numeric value representing the highest interrupt priority allowed to call FreeRTOS API, typically a mid-level priority like 0x80.

3. Final Answer:

   0x80 // Mid-level priority -> Option A

4. Quick Check:

   Priority value must be numeric, not string [OK]

Hint: Use numeric hex values for priorities, not strings [OK]

Common Mistakes:

• Using string instead of numeric value
• Setting priority to 0x00 (too high)
• Using lowest priority 0xFF which disables API calls

3.

Given configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x50, which ISR priority can safely call FreeRTOS API functions?

ISR Priority Options:
A) 0x40
B) 0x50
C) 0x60
D) 0x30

medium

A. 0x40

B. 0x30

C. 0x50

D. 0x60

Solution

1. Step 1: Compare ISR priorities with configMAX_SYSCALL_INTERRUPT_PRIORITY

   Only ISRs with priority equal or numerically higher (lower urgency) than 0x50 can call FreeRTOS API.

2. Step 2: Evaluate each option

   0x40 and 0x30 are higher priority (lower number) than 0x50, so cannot call API. 0x50 equals limit, allowed. 0x60 is lower priority (higher number), also allowed.

3. Final Answer:

   0x50 and 0x60 -> Option D

4. Quick Check:

   ISR priority must be >= configMAX_SYSCALL_INTERRUPT_PRIORITY [OK]

Hint: ISR priority must be equal or lower urgency than configMAX_SYSCALL_INTERRUPT_PRIORITY [OK]

Common Mistakes:

• Confusing numeric priority order
• Allowing higher urgency ISRs to call API
• Ignoring equal priority as allowed

4.

Identify the error in this ISR code snippet if configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x60:

void ISR_Handler(void) {
    NVIC_SetPriority(IRQn, 0x40);
    vTaskNotifyGiveFromISR(taskHandle, NULL);
}

medium

A. ISR priority 0x40 is higher than allowed to call FreeRTOS API

B. vTaskNotifyGiveFromISR cannot be called from ISR

C. NVIC_SetPriority should not be called inside ISR

D. No error, code is correct

Solution

1. Step 1: Check ISR priority against configMAX_SYSCALL_INTERRUPT_PRIORITY

   Priority 0x40 is higher urgency (lower number) than 0x60, so ISR cannot safely call FreeRTOS API.

2. Step 2: Analyze API call in ISR

   Calling vTaskNotifyGiveFromISR requires ISR priority at or below 0x60, which is violated here.

3. Final Answer:

   ISR priority 0x40 is higher than allowed to call FreeRTOS API -> Option A

4. Quick Check:

   ISR priority must not exceed configMAX_SYSCALL_INTERRUPT_PRIORITY [OK]

Hint: ISR priority must be equal or lower urgency than configMAX_SYSCALL_INTERRUPT_PRIORITY [OK]

Common Mistakes:

• Ignoring priority set inside ISR
• Thinking API calls are always allowed in ISR
• Confusing priority numeric order

5.

You have two ISRs: ISR_A with priority 0x70 and ISR_B with priority 0x40. configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 0x60. Which statement is true?

hard

A. Neither ISR can call FreeRTOS API

B. ISR_A can call FreeRTOS API, ISR_B cannot

C. Both ISRs can call FreeRTOS API safely

D. ISR_B can call FreeRTOS API, ISR_A cannot

Solution

1. Step 1: Compare ISR priorities with configMAX_SYSCALL_INTERRUPT_PRIORITY

   Only ISRs with priority numerically equal or higher (lower urgency) than 0x60 can call FreeRTOS API.

2. Step 2: Evaluate ISR_A and ISR_B priorities

   ISR_A priority 0x70 is lower urgency than 0x60, so it can call API. ISR_B priority 0x40 is higher urgency, so it cannot.

3. Final Answer:

   ISR_A can call FreeRTOS API, ISR_B cannot -> Option B

4. Quick Check:

   Only ISRs with priority >= configMAX_SYSCALL_INTERRUPT_PRIORITY call API [OK]

Hint: Only ISRs with priority numerically >= configMAX_SYSCALL_INTERRUPT_PRIORITY call API [OK]

Common Mistakes:

• Assuming higher urgency ISRs can call API
• Confusing numeric priority order
• Thinking all ISRs can call API regardless of priority