RTOS API Calls from ISRs: Constraints and 'FromISR' Usage

1. The Fundamental Constraint: Task Context vs. Interrupt Context

First, let's address a crucial question: why can't we just call a function like xQueueSend() or xSemaphoreTake() from an Interrupt Service Routine (ISR)?

The answer lies in the concept of execution context.

• Task Context: A task is a formal entity managed by the RTOS scheduler. It has its own stack, a priority, and a state (Running, Ready, Blocked, Suspended). The scheduler can choose to stop a task and place it in the Blocked state—for example, if it's waiting for a queue to receive data. This is a normal, healthy part of multitasking.

• Interrupt Context: An ISR is a raw hardware response to an event. It is not a task. It preempts the currently running task (and the scheduler) and takes over the CPU. An ISR does not have its own dedicated task state; it "borrows" the context of whatever was running. Crucially, an ISR can never be placed in the Blocked state. If an ISR were to block, it would never be "woken up" by the scheduler because the scheduler itself is preempted. The system would effectively hang, waiting for an interrupt to finish that will never finish.

This is why calling a standard RTOS API function with a non-zero block time from an ISR is strictly forbidden. It would attempt to block a non-task, leading to catastrophic failure.

2. The Solution: Interrupt-Safe ...FromISR Functions

To solve this, FreeRTOS provides a special set of API functions that are guaranteed to be safe to call from an ISR. They are easily identifiable by their ...FromISR suffix, for example:

• xSemaphoreGiveFromISR()
• xQueueSendToBackFromISR()
• xQueueReceiveFromISR()

These functions are different from their standard counterparts in two critical ways:

1. They never block. They are designed to execute and return immediately. If a queue is full, xQueueSendToBackFromISR() will not wait; it will simply return an error (errQUEUE_FULL).
2. They manage context switching differently. They include an extra parameter, pxHigherPriorityTaskWoken, which is the key to efficient scheduling from an interrupt.

3. Deferred Context Switching

When an ISR uses a ...FromISR function to, say, give a semaphore, it might unblock a task that was waiting for it. If this newly-unblocked task has a higher priority than the task that was originally interrupted, the scheduler should switch to it as soon as the ISR completes.

However, an ISR can't just call the scheduler directly. Doing so in the middle of an ISR could be inefficient, especially if the ISR gives multiple semaphores or sends multiple queue items. The ideal time to perform a context switch is right at the very end of the interrupt handler.

This is managed by a mechanism called deferred context switching:

1. Before calling a ...FromISR function, you declare a local variable: BaseType_t xHigherPriorityTaskWoken = pdFALSE;
2. You pass a pointer to this variable into the ...FromISR function (e.g., xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);).
3. Inside the API function, if unblocking a task results in a higher-priority task becoming ready to run, the function sets xHigherPriorityTaskWoken to pdTRUE.
4. At the end of your ISR, you call a special macro, portYIELD_FROM_ISR(xHigherPriorityTaskWoken);.
5. This macro checks the value of the flag. If it's pdTRUE, it requests a context switch. If it's pdFALSE, it does nothing.

This ensures that a context switch is requested only if necessary, and it happens just once before exiting the interrupt, making the system highly efficient.

4. Practical Implementation Patterns

This "deferred interrupt processing" pattern is fundamental. The ISR does the absolute minimum work (e.g., read a hardware register, clear an interrupt flag) and then signals a dedicated task to do the heavy lifting.

Pattern 1: Synchronizing with a Semaphore

This is the classic way to signal an event. An ISR "gives" a semaphore, and a high-priority task that was "taking" (and thus blocked on) that semaphore wakes up to process the event.

Here's the essential code flow:

The Handler Task:

void vHandlerTask(void *pvParameters) {
    for (;;) {
        // Block indefinitely, waiting for the semaphore from the ISR.
        if (xSemaphoreTake(xBinarySemaphore, portMAX_DELAY) == pdTRUE) {
            // The ISR has occurred. Process the event.
            process_the_data();
        }
    }
}

The Interrupt Service Routine:

void UART_RX_IRQHandler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;

    // Minimal work: clear the interrupt flag
    UART->SR &= ~UART_FLAG_RXNE;

    // Unblock the handler task.
    xSemaphoreGiveFromISR(xBinarySemaphore, &xHigherPriorityTaskWoken);

    // If xHigherPriorityTaskWoken is now pdTRUE, a context switch will be requested.
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Pattern 2: Passing Data with a Queue

This builds directly on our last lesson. A semaphore just signals an event; a queue can signal an event and pass along associated data.

5. A Critical Detail: Interrupt Priorities

Here we move into an advanced topic that is essential for a senior developer role and a common source of hard-to-find bugs if misunderstood.

On ARM Cortex-M3/M4/M7 cores, FreeRTOS does not disable all interrupts when it enters a critical section. Instead, it disables interrupts only up to a certain configurable priority level. This allows very high-priority, low-latency interrupts to run even when the kernel is busy.

This behavior is controlled by configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h.

THE GOLDEN RULE: Any ISR that calls an interrupt-safe FreeRTOS API function (...FromISR) MUST have a hardware interrupt priority that is numerically equal to or greater than configMAX_SYSCALL_INTERRUPT_PRIORITY.

Remember that on ARM Cortex-M, a lower priority number means a higher logical priority. So if configMAX_SYSCALL_INTERRUPT_PRIORITY is 5, your ISR that calls xQueueSendFromISR must be configured with a priority of 5, 6, 7, etc. An ISR with priority 4 would be of a higher urgency and would not be blocked by the RTOS kernel. However, that ISR is forbidden from calling any FreeRTOS API functions, as it could corrupt the kernel's internal state.

6. Interview Preparation: Key Questions

• Question: "Why can't you call a standard FreeRTOS API function like vTaskDelay or xQueueSend from an ISR? What would happen?"

  • Your Answer: "You can't call blocking functions from an ISR because an ISR doesn't have a task context that can be put into a Blocked state. An ISR preempts the scheduler itself. If it were to block, the system would hang as there is no mechanism for the scheduler to unblock it. Standard APIs might also not be reentrant in a way that is safe from interrupt context. This is why FreeRTOS provides special, non-blocking ...FromISR variants."

• Question: "Explain the purpose of the pxHigherPriorityTaskWoken parameter and the portYIELD_FROM_ISR macro. Why is this 'deferred' context switch mechanism used?"

  • Your Answer: "When an ISR unblocks a task, that task might have a higher priority than the task that was interrupted. The pxHigherPriorityTaskWoken parameter is a flag used by the ...FromISR function to signal that such a situation has occurred. The ISR checks this flag at the end and calls portYIELD_FROM_ISR to request a context switch. This 'deferred' mechanism is efficient because it ensures the scheduler only runs once at the conclusion of the ISR, rather than potentially multiple times within it, and it ensures the system returns directly to the highest priority task that is now ready to run."

• Question: "You're debugging a system where calls to xQueueSendFromISR seem to be corrupting kernel data structures, causing random crashes. The ISR itself seems simple. What's one of the first configuration settings you would check?"

  • Your Answer: "I would immediately check the hardware priority of the ISR in the NVIC and compare it against the configMAX_SYSCALL_INTERRUPT_PRIORITY setting in FreeRTOSConfig.h. This type of corruption is a classic symptom of an ISR calling a FreeRTOS API function from a logically higher (numerically lower) interrupt priority than is permitted. Such an interrupt isn't being correctly masked by the kernel's critical sections, allowing it to run concurrently with kernel operations and leading to race conditions and data corruption. The ISR's priority must be numerically equal to or greater than configMAX_SYSCALL_INTERRUPT_PRIORITY."

Conclusion

You've now covered one of the most important and nuanced topics in RTOS programming. Properly handling interrupts and synchronizing them with tasks is the hallmark of a robust embedded system.

Key Takeaways:

• ISRs operate in a constrained interrupt context and must never block.
• Always use the non-blocking ...FromISR API variants to communicate with the RTOS from an interrupt.
• Use the xHigherPriorityTaskWoken and portYIELD_FROM_ISR pattern to efficiently perform a context switch at the end of an ISR.
• Critically, ensure the hardware priority of any ISR calling a FreeRTOS API function is configured correctly with respect to configMAX_SYSCALL_INTERRUPT_PRIORITY.

Next Lesson Preview:
We've talked a lot about tasks changing states, context switches, and ISRs preempting tasks. In our next lesson, we will learn how to actually see this happening. We will cover the learning outcome: Analyze RTOS behavior, including task states, context switches, and timing, using debugger trace features. This will allow you to visually confirm the concepts we've discussed and provide powerful tools for debugging complex timing issues.