Nested interrupt handling in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of nested interrupt priority handling

Consider a FreeRTOS system with two interrupts: ISR1 with priority 3 and ISR2 with priority 2 (lower number means higher priority). ISR1 triggers ISR2. What will be the output sequence?

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include <stdio.h>

volatile int output = 0;

void ISR2_Handler(void) {
    output = output * 10 + 2;
}

void ISR1_Handler(void) {
    output = output * 10 + 1;
    // Simulate triggering ISR2
    ISR2_Handler();
    output = output * 10 + 3;
}

int main() {
    output = 0;
    ISR1_Handler();
    printf("%d", output);
    return 0;
}

A 123

B 132

C 12

D 321

💡 Hint

Think about the order in which the interrupts execute and how nested interrupts affect the output.

ISR1 starts and appends '1'. Then it triggers ISR2 which appends '2'. After ISR2 finishes, ISR1 resumes and appends '3'. So the output is '123'.

🧠 Conceptual

intermediate

Which interrupt can preempt in nested handling?

In FreeRTOS, if two interrupts have priorities 5 and 7 (lower number means higher priority), which interrupt can preempt the other during nested interrupt handling?

A Interrupt with priority 7 can preempt priority 5

B Interrupt with priority 5 can preempt priority 7

C Neither can preempt each other

D Both can preempt each other simultaneously

💡 Hint

Remember that lower priority number means higher priority in FreeRTOS.

In FreeRTOS, lower priority number means higher priority. So priority 5 is higher than 7 and can preempt it.

🔧 Debug

advanced

Identify the error in nested interrupt enabling

What error will occur with this nested interrupt code snippet in FreeRTOS?

FreeRTOS

void ISR1_Handler(void) {
    portDISABLE_INTERRUPTS();
    // Critical section
    portENABLE_INTERRUPTS();
    ISR2_Handler();
}

void ISR2_Handler(void) {
    // Nested interrupt code
}

A Compilation error due to missing semicolon

B Nested interrupt will run correctly without issues

C Stack overflow due to recursive interrupts

D ISR2 will never run because interrupts are disabled

💡 Hint

Check when interrupts are enabled or disabled during nested calls.

Interrupts are disabled before ISR2 is called, so ISR2 cannot run as a nested interrupt.

📝 Syntax

advanced

Identify syntax error in nested interrupt declaration

Which option contains a syntax error in declaring nested interrupt handlers in FreeRTOS?

FreeRTOS

void ISR1_Handler(void) __attribute__((interrupt));
void ISR2_Handler(void) __attribute__((interrupt));

A void ISR1_Handler(void) __attribute__((interrupt));

B void ISR1_Handler() __attribute__((interrupt));

C void ISR2_Handler(void) __attribute__((interrupt) {});

D void ISR2_Handler(void) __attribute__((interrupt));

💡 Hint

Look carefully at the attribute syntax and function declaration.

Option C has incorrect syntax: the attribute is followed by braces which is invalid.

🚀 Application

expert

Calculate maximum nested interrupt depth

Given a FreeRTOS system with 8 interrupt priority levels (0 highest, 7 lowest), and nested interrupts allowed only if the new interrupt has higher priority, what is the maximum possible nested interrupt depth starting from priority 7?

A 7

B 8

C 1

D 0

💡 Hint

Think about how many higher priority interrupts exist above priority 7.

Starting from priority 7, interrupts with priorities 6,5,4,3,2,1,0 can preempt, so maximum nested depth is 7.

Practice

1.

What is the main purpose of nested interrupt handling in FreeRTOS?

easy

A. Allow higher priority interrupts to interrupt lower priority ones

B. Disable all interrupts during task switching

C. Prevent any interrupt from occurring during critical sections

D. Run all interrupts sequentially without interruption

Solution

1. Step 1: Understand interrupt priorities

   Nested interrupts allow interrupts with higher priority to interrupt those with lower priority.

2. Step 2: Relate to FreeRTOS behavior

   FreeRTOS supports nested interrupts to ensure urgent tasks get immediate attention.

3. Final Answer:

   Allow higher priority interrupts to interrupt lower priority ones -> Option A

4. Quick Check:

   Nested interrupts = higher priority interrupts interrupting lower priority [OK]

Hint: Nested interrupts let urgent interrupts pause less urgent ones [OK]

Common Mistakes:

• Thinking all interrupts are disabled during task switching
• Believing interrupts run only sequentially without nesting
• Confusing nested interrupts with disabling interrupts

2.

Which of the following is the correct way to yield from an ISR in FreeRTOS?

void ISR_Handler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    // Some ISR code
    // ...
    // Yield if needed
    ?
}

easy

A. taskYIELD();

B. portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

C. vTaskDelay(1);

D. portEND_SWITCHING_ISR(xHigherPriorityTaskWoken);

Solution

1. Step 1: Identify correct ISR yield function

   In FreeRTOS, portYIELD_FROM_ISR is used to request a context switch from an ISR safely.

2. Step 2: Check other options

   taskYIELD is for tasks, vTaskDelay is for delaying tasks, portEND_SWITCHING_ISR is not a FreeRTOS API.

3. Final Answer:

   portYIELD_FROM_ISR(xHigherPriorityTaskWoken); -> Option B

4. Quick Check:

   Yield from ISR = portYIELD_FROM_ISR [OK]

Hint: Use portYIELD_FROM_ISR to yield safely inside ISRs [OK]

Common Mistakes:

• Using taskYIELD inside ISR causing errors
• Calling vTaskDelay inside ISR which is invalid
• Confusing portEND_SWITCHING_ISR with portYIELD_FROM_ISR

3.

Given the following FreeRTOS ISR code snippet, what will be the value of xHigherPriorityTaskWoken after execution?

void ISR_Timer(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Assume the semaphore unblocks a higher priority task waiting.

medium

A. Undefined behavior

B. pdFALSE

C. pdTRUE

D. Semaphore handle value

Solution

1. Step 1: Understand xSemaphoreGiveFromISR behavior

   This function sets xHigherPriorityTaskWoken to pdTRUE if a higher priority task is unblocked.

2. Step 2: Given higher priority task is unblocked

   Since the semaphore unblocks a higher priority task, xHigherPriorityTaskWoken becomes pdTRUE.

3. Final Answer:

   pdTRUE -> Option C

4. Quick Check:

   Higher priority task unblocked = xHigherPriorityTaskWoken pdTRUE [OK]

Hint: xHigherPriorityTaskWoken is pdTRUE if higher priority task unblocked [OK]

Common Mistakes:

• Assuming xHigherPriorityTaskWoken stays pdFALSE always
• Confusing semaphore handle with boolean flag
• Ignoring the effect of unblocking higher priority tasks

4.

Identify the error in this nested interrupt handling code snippet:

void ISR_UART(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xQueueSendFromISR(xQueue, &data, NULL);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

medium

A. BaseType_t should be int instead

B. portYIELD_FROM_ISR should not be called inside ISR

C. xQueueSendFromISR cannot be used in ISRs

D. xHigherPriorityTaskWoken should be passed to xQueueSendFromISR

Solution

1. Step 1: Check xQueueSendFromISR parameters

   The function requires a pointer to xHigherPriorityTaskWoken to update it if a higher priority task is woken.

2. Step 2: Identify missing argument

   Passing NULL means xHigherPriorityTaskWoken is never updated, so portYIELD_FROM_ISR may not yield correctly.

3. Final Answer:

   xHigherPriorityTaskWoken should be passed to xQueueSendFromISR -> Option D

4. Quick Check:

   Pass xHigherPriorityTaskWoken pointer to FromISR APIs [OK]

Hint: Always pass xHigherPriorityTaskWoken pointer to FromISR APIs [OK]

Common Mistakes:

• Passing NULL instead of &xHigherPriorityTaskWoken
• Calling portYIELD_FROM_ISR without updating flag
• Using wrong variable types for task woken flag

5.

You want to implement nested interrupt handling where a high priority interrupt can preempt a low priority one and safely switch tasks if needed. Which combination of steps is correct?

1. Configure interrupt priorities properly
2. Use portYIELD_FROM_ISR() inside ISRs
3. Disable all interrupts during ISR execution
4. Use FromISR API versions for FreeRTOS calls inside ISRs

Choose the best combination.

hard

A. 1, 2, and 4 only

B. 1 and 3 only

C. 2, 3, and 4 only

D. All four steps

Solution

1. Step 1: Configure interrupt priorities

   Proper priority setup allows nested interrupts to work correctly.

2. Step 2: Use portYIELD_FROM_ISR and FromISR APIs

   These ensure safe task switching and API calls inside ISRs.

3. Step 3: Avoid disabling all interrupts during ISR

   Disabling all interrupts prevents nesting, so step 3 is incorrect.

4. Final Answer:

   1, 2, and 4 only -> Option A

5. Quick Check:

   Nested interrupts need priorities + FromISR APIs + portYIELD_FROM_ISR [OK]

Hint: Use priorities and FromISR APIs; don't disable all interrupts [OK]

Common Mistakes:

• Disabling all interrupts prevents nesting
• Forgetting to use FromISR API versions
• Ignoring interrupt priority configuration