Nested interrupt handling in FreeRTOS - Step-by-Step Execution

Concept Flow - Nested interrupt handling

Interrupt 1 occurs

↓

Interrupt 1 handler starts

↓

Interrupt 2 occurs (higher priority)

↓

Interrupt 1 paused

↓

Interrupt 2 handler runs

↓

Interrupt 2 handler ends

↓

Interrupt 1 resumes

↓

Interrupt 1 handler ends

↓

Return to main program

When a higher priority interrupt occurs during a lower priority interrupt, the lower one pauses, the higher runs, then the lower resumes.

Execution Sample

FreeRTOS

void ISR1() {
  // Start ISR1
  if (higher_priority_interrupt) {
    ISR2(); // Nested interrupt
  }
  // Finish ISR1
}

void ISR2() {
  // Handle higher priority interrupt
}

Shows ISR1 starting, then ISR2 interrupting it, then ISR1 resuming after ISR2 finishes.

Execution Table

Step	Event	Current ISR	Action	State
1	Interrupt 1 occurs	None	Start ISR1	ISR1 running
2	Interrupt 2 occurs (higher priority)	ISR1	Pause ISR1, start ISR2	ISR1 paused, ISR2 running
3	ISR2 completes	ISR2	End ISR2, resume ISR1	ISR1 running
4	ISR1 completes	ISR1	End ISR1	No ISR running, return to main
5	Main program resumes	None	Continue normal execution	Main running

💡 All interrupts handled, system returns to main program

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
ISR State	None	ISR1 running	ISR1 paused, ISR2 running	ISR1 running	No ISR running	No ISR running

Key Moments - 3 Insights

Why does ISR1 pause when ISR2 starts?

Because ISR2 has higher priority, the system pauses ISR1 to handle ISR2 first, as shown in step 2 of the execution_table.

How does the system know to resume ISR1 after ISR2 finishes?

After ISR2 ends (step 3), the system resumes the paused ISR1 automatically, continuing from where it left off.

What happens if a lower priority interrupt occurs during ISR1?

Lower priority interrupts wait until ISR1 finishes; they do not interrupt ISR1, unlike higher priority interrupts.

Visual Quiz - 3 Questions

Look at the execution_table, what is the ISR state after step 2?

A ISR1 running, ISR2 paused

B ISR1 paused, ISR2 running

C No ISR running

D ISR2 paused, ISR1 running

💡 Hint

Check the 'State' column in row for step 2 in execution_table

At which step does ISR1 resume after being paused?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' column in execution_table for when ISR1 resumes

If ISR2 had lower priority than ISR1, what would happen at step 2?

A ISR2 waits until ISR1 finishes

B Both ISR1 and ISR2 run simultaneously

C ISR1 pauses and ISR2 runs

D ISR2 cancels ISR1

💡 Hint

Recall that only higher priority interrupts can preempt lower ones, see key_moments explanation

Concept Snapshot

Nested interrupt handling allows higher priority interrupts to pause lower priority ones.
Lower priority interrupts wait until current ISR finishes.
ISR state changes: running -> paused -> resumed.
System returns to main program after all ISRs complete.
This ensures urgent tasks get immediate attention.

Full Transcript

Nested interrupt handling means when a higher priority interrupt happens during a lower priority interrupt, the lower one pauses and the higher one runs. After the higher priority interrupt finishes, the lower priority interrupt resumes. This process ensures urgent tasks are handled immediately without losing progress on the interrupted task. The execution table shows step-by-step how ISR1 starts, ISR2 interrupts it, ISR2 finishes, then ISR1 resumes and finishes, returning control to the main program.

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