Bird
Raised Fist0
FreeRTOSprogramming~30 mins

Nested interrupt handling in FreeRTOS - Mini Project: Build & Apply

Choose your learning style10 modes available
Nested Interrupt Handling in FreeRTOS
📖 Scenario: You are working on a microcontroller project using FreeRTOS. Your device needs to handle two interrupts: a high priority timer interrupt and a lower priority sensor interrupt. The timer interrupt can occur anytime, even while the sensor interrupt is running. You want to make sure the timer interrupt can interrupt the sensor interrupt (nested interrupts) and both handlers update shared counters safely.
🎯 Goal: Build a simple FreeRTOS program that sets up two interrupt handlers with different priorities. The timer interrupt handler should be able to interrupt the sensor interrupt handler. Both handlers will increment their own counters. You will configure the interrupts, write the handlers, and print the final counts.
📋 What You'll Learn
Create two global counters: timer_count and sensor_count
Configure two interrupts: TIMER_IRQn with higher priority and SENSOR_IRQn with lower priority
Write interrupt handlers TIMER_IRQHandler and SENSOR_IRQHandler that increment their counters
Enable nested interrupts so TIMER_IRQHandler can interrupt SENSOR_IRQHandler
Print the values of timer_count and sensor_count after simulating interrupts
💡 Why This Matters
🌍 Real World
Embedded systems often need to handle multiple interrupts with different priorities. Nested interrupts allow urgent tasks to interrupt less urgent ones, improving responsiveness.
💼 Career
Understanding nested interrupt handling is essential for embedded software engineers working on real-time systems, device drivers, and hardware interfacing.
Progress0 / 4 steps
1
Create global counters for interrupts
Create two global variables called timer_count and sensor_count and initialize both to 0.
FreeRTOS
Hint

Use volatile int for counters because they are changed inside interrupts.

2
Configure interrupt priorities
Write code to set the priority of TIMER_IRQn to 1 (higher priority) and SENSOR_IRQn to 2 (lower priority) using NVIC_SetPriority. Then enable both interrupts with NVIC_EnableIRQ.
FreeRTOS
Hint

Lower number means higher priority in NVIC_SetPriority.

3
Write nested interrupt handlers
Write two interrupt handlers: void TIMER_IRQHandler(void) and void SENSOR_IRQHandler(void). In each handler, increment the respective counter (timer_count or sensor_count). In SENSOR_IRQHandler, enable interrupts at the start to allow nesting by calling __enable_irq(). In TIMER_IRQHandler, just increment the counter.
FreeRTOS
Hint

Call __enable_irq() inside SENSOR_IRQHandler to allow higher priority interrupts to nest.

4
Simulate interrupts and print counters
Simulate calling SENSOR_IRQHandler() followed by TIMER_IRQHandler() twice. Then print the values of timer_count and sensor_count using printf in the format: "Timer count: X, Sensor count: Y" where X and Y are the counter values.
FreeRTOS
Hint

Call the handlers in the order specified and print the counters with printf.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard