Deferred interrupt processing architecture in FreeRTOS - Step-by-Step Execution

Concept Flow - Deferred interrupt processing architecture

Interrupt Occurs

↓

ISR Starts

↓

Quick ISR Work

↓

Schedule Deferred Handler

↓

ISR Ends

↓

Deferred Handler Runs in Task Context

↓

Complete Processing

When an interrupt happens, the ISR does only quick work and schedules a deferred handler to finish the job later in normal task context.

Execution Sample

FreeRTOS

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

void DeferredTask(void *pvParameters) {
  for(;;) {
    xSemaphoreTake(xSemaphore, portMAX_DELAY);
    // Process deferred work
  }
}

ISR quickly gives a semaphore to unblock a task that does the deferred processing.

Execution Table

Step	Action	ISR Work	Deferred Handler Work	Context Switch
1	Interrupt occurs	Start ISR	No	No
2	ISR gives semaphore	Give semaphore	No	No
3	ISR ends	Exit ISR	No	Possible if higher priority task unblocked
4	Deferred task unblocked	No	Unblocked, waiting for semaphore	No
5	Deferred task takes semaphore	No	Take semaphore	No
6	Deferred task processes work	No	Process deferred work	No
7	Deferred task loops back	No	Wait for next semaphore	No

💡 ISR finishes quickly; deferred task handles full processing after semaphore is given.

Variable Tracker

Variable	Start	After ISR Step 2	After Deferred Task Step 5	Final
xHigherPriorityTaskWoken	pdFALSE	pdTRUE if task unblocked	N/A	N/A
xSemaphore	Empty	Given by ISR	Taken by deferred task	Empty after take

Key Moments - 3 Insights

Why does the ISR only give a semaphore and not do the full processing?

The ISR must be very fast to avoid blocking other interrupts. The full processing is deferred to a task context, as shown in execution_table rows 2 and 6.

How does the deferred task know when to run?

The deferred task waits on a semaphore. When the ISR gives the semaphore (row 2), the task unblocks and runs (rows 5 and 6).

What triggers a context switch after the ISR?

If the ISR unblocks a higher priority task (xHigherPriorityTaskWoken becomes true), portYIELD_FROM_ISR triggers a context switch (row 3).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the ISR give the semaphore?

A Step 4

B Step 2

C Step 5

D Step 6

💡 Hint

Check the 'ISR Work' column for when the semaphore is given.

According to variable_tracker, what is the state of xSemaphore after the deferred task takes it?

A Given by ISR

B Taken by deferred task

C Empty

D pdTRUE

💡 Hint

Look at the 'Final' column for xSemaphore in variable_tracker.

If the ISR did all processing inside itself, what would likely happen?

A Other interrupts might be delayed

B ISR would be faster

C Deferred task would run sooner

D Semaphore would not be needed

💡 Hint

Refer to key_moments about ISR speed and deferred processing.

Concept Snapshot

Deferred interrupt processing means:
- ISR does minimal, quick work
- ISR signals a task (e.g., via semaphore)
- Deferred task does heavy processing
- Keeps ISR fast and responsive
- Uses FreeRTOS primitives like xSemaphoreGiveFromISR
- Context switch may happen if higher priority task unblocked

Full Transcript

Deferred interrupt processing architecture in FreeRTOS means that when an interrupt occurs, the interrupt service routine (ISR) does only the minimal necessary work quickly, such as giving a semaphore. This semaphore unblocks a deferred task that runs in normal task context to complete the heavier processing. This approach keeps the ISR short and responsive, avoiding delays to other interrupts. The ISR uses functions like xSemaphoreGiveFromISR and may trigger a context switch if a higher priority task is unblocked. The deferred task waits on the semaphore and processes the work when unblocked. This design improves system responsiveness and reliability.

Practice

1. What is the main purpose of deferred interrupt processing in FreeRTOS?

easy

A. To disable all interrupts during task execution

B. To execute all interrupt code inside the ISR for speed

C. To split interrupt handling between a fast ISR and a slower task

D. To avoid using queues or notifications in interrupt handling

Solution

1. Step 1: Understand ISR limitations

   ISRs should be short to keep system responsive and avoid blocking other interrupts.

2. Step 2: Role of deferred processing

   Deferred processing moves longer work to a task, improving system reliability and responsiveness.

3. Final Answer:

   To split interrupt handling between a fast ISR and a slower task -> Option C

4. Quick Check:

   Deferred interrupt processing = splitting work [OK]

Hint: Remember: ISR is fast, task does the heavy work [OK]

Common Mistakes:

• Thinking all work should be done inside ISR
• Believing interrupts are disabled during task execution
• Ignoring the use of task notifications or queues

2. Which of the following is the correct way to notify a task from an ISR in FreeRTOS?

easy

A. xTaskNotifyGiveFromISR(taskHandle, &higherPriorityTaskWoken);

B. xTaskNotifyGive(taskHandle);

C. vTaskDelay(10);

D. xQueueSend(queueHandle, &data, portMAX_DELAY);

Solution

1. Step 1: Identify ISR-safe notification function

   Only functions ending with 'FromISR' are safe to call inside ISRs.

2. Step 2: Check options

   xTaskNotifyGiveFromISR is designed for ISR context; others are not ISR-safe or unrelated.

3. Final Answer:

   xTaskNotifyGiveFromISR(taskHandle, &higherPriorityTaskWoken); -> Option A

4. Quick Check:

   ISR notification uses FromISR functions [OK]

Hint: Use 'FromISR' functions inside ISRs only [OK]

Common Mistakes:

• Using normal task notification functions inside ISR
• Calling blocking functions like vTaskDelay in ISR
• Using queue send with infinite block time inside ISR

3. Given the following code snippet, what will be the output?

void ISR_Handler() {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    xTaskNotifyGiveFromISR(taskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void TaskFunction(void *pvParameters) {
    for(;;) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        printf("Task notified\n");
    }
}

medium

A. Task notified printed only once

B. No output because task is never notified

C. Compilation error due to missing parameters

D. Task notified printed each time ISR runs

Solution

1. Step 1: Analyze ISR notification

   ISR calls xTaskNotifyGiveFromISR which increments the task's notification count and may cause context switch.

2. Step 2: Analyze task behavior

   Task blocks on ulTaskNotifyTake until notified, then prints "Task notified" and loops back to wait again.

3. Final Answer:

   Task notified printed each time ISR runs -> Option D

4. Quick Check:

   ISR notifies task -> task prints [OK]

Hint: ISR notification wakes task repeatedly [OK]

Common Mistakes:

• Assuming task never wakes up
• Confusing notification count with binary flag
• Thinking task prints only once

4. Identify the error in this deferred interrupt processing code snippet:

void ISR_Handler() {
    xQueueSend(queueHandle, &data, portMAX_DELAY);
}

void TaskFunction(void *pvParameters) {
    for(;;) {
        if(xQueueReceive(queueHandle, &receivedData, portMAX_DELAY) == pdPASS) {
            process(receivedData);
        }
    }
}

medium

A. xQueueReceive should be called from ISR

B. Using portMAX_DELAY in ISR causes a blocking call

C. ISR should not send data to queue

D. Task should not block on queue receive

Solution

1. Step 1: Check ISR queue send parameters

   portMAX_DELAY causes blocking; ISRs must never block or wait.

2. Step 2: Correct usage in ISR

   Use xQueueSendFromISR with zero block time to avoid blocking in ISR.

3. Final Answer:

   Using portMAX_DELAY in ISR causes a blocking call -> Option B

4. Quick Check:

   ISRs must not block = no portMAX_DELAY in ISR [OK]

Hint: Never block inside ISR; use FromISR functions with zero wait [OK]

Common Mistakes:

• Using blocking calls inside ISR
• Calling task functions from ISR
• Confusing ISR and task context functions

5. You want to design a deferred interrupt processing system where multiple ISRs notify a single task to process different events. Which approach best ensures the task processes all events without missing any notifications?

hard

A. Use a queue to send event data from each ISR to the task

B. Use xTaskNotifyGiveFromISR from each ISR without data

C. Use global flags set by ISRs and polled by the task

D. Disable interrupts while the task processes events

Solution

1. Step 1: Understand notification limitations

   xTaskNotifyGiveFromISR increments a count but cannot carry event data, risking lost info if multiple events occur quickly.

2. Step 2: Use queue for event data

   Queues can hold multiple event messages safely, ensuring the task processes all events without loss.

3. Final Answer:

   Use a queue to send event data from each ISR to the task -> Option A

4. Quick Check:

   Queues hold multiple events safely [OK]

Hint: Use queues to handle multiple event data safely [OK]

Common Mistakes:

• Relying on notifications without event data
• Using global flags causing race conditions
• Disabling interrupts too long hurting responsiveness