5.4Interrupt handlers & resource management

Interrupts are the core mechanism by which an embedded system reacts to external events in real time, but packing too much processing into an interrupt handler (ISR) stalls other interrupts and normal processing for that duration, harming the responsiveness of the system as a whole. Furthermore, if the ISR and normal processing share the same variable, data can become corrupted depending on timing. This section covers how an ISR should be designed and how to protect shared resources—judgments that determine the reliability of embedded software.

5.4.1ISR design principles (keep short, defer processing)

• An ISR (interrupt service routine) is the processing the CPU executes when an interrupt occurs. While an ISR is running, interrupts at the same or a lower level are masked and cannot be accepted, so the longer an ISR runs, the more other interrupt handling is delayed, degrading the real-time responsiveness of the system as a whole. The principle is: "do only the bare minimum inside the ISR (clearing the interrupt cause, saving critical data, etc.), and defer time-consuming processing to normal (task-level) processing."
• A common deferral implementation pattern is for the ISR to only store received data in a buffer and set a flag or semaphore, while the actual data processing and communication handling are done on the normal task side (main loop or RTOS task). This minimizes interrupt-response delay (interrupt latency) while still allowing time-consuming processing to run.

5.4.2Reentrancy and critical sections

• Reentrant (re-entrant) describes a property where, if a function is interrupted mid-execution and the same function is then invoked again from the interrupt handler (or another task), both invocations execute correctly without affecting each other's results. The basic way to ensure reentrancy is to avoid dependence on static or global variables and complete the work using only local variables (on the stack). A shared function that might be called from an ISR must be designed to be reentrant.
• When an ISR and normal processing (or multiple tasks) read and write the same global variable or shared buffer, if one process is interrupted in an incomplete state and the other accesses that variable, data can be corrupted (a race condition). To prevent this, access to a shared variable is wrapped in a critical section (an interrupt-disabled region or a mutual-exclusion lock), temporarily blocking interruption by other processing. However, making the critical section too long degrades real-time responsiveness, since interrupts cannot be responded to during that time, so the design essential is to keep it to the minimum necessary scope.

Suppose a firmware developer builds a system where a timer interrupt periodically aggregates data arriving from multiple sensors, and the normal main loop reads that aggregated result to send it to an upstream system, and then encounters a data-corruption bug. Investigating, they find that the timer-interrupt ISR reads and writes a 32-bit global variable (the aggregate value), and the main loop also directly reads the same global variable. Because the CPU in use is an 8-bit MCU, where access to a 32-bit variable is split into multiple instructions (multi-byte reads/writes), they judge that a race condition can occur where a timer interrupt fires while the main loop is mid-read of that variable, causing the loop to read an inconsistent value with the upper byte already updated but the lower byte still old. Based on this diagnosis, they wrap the moment just before and after the main loop reads the aggregate value in a critical section (temporarily disabling interrupts), so the timer interrupt cannot rewrite the aggregate value during the read. However, extending the critical section over the entire aggregation process would block the timer interrupt itself for an extended time and disrupt other real-time processing, so they narrow its scope to just the minimum few instructions needed to read the 32-bit variable. Furthermore, because the shared utility function invoked by this aggregation process used a static variable, they judged there was a risk of cross-contamination if it were called from both the ISR and the main loop, and fixed the implementation to be reentrant by replacing the static variable with a local variable (on the stack). In this way, the core of reliability design around interrupt handlers is to identify the resources shared between the ISR and normal processing, protect only the spots where a race condition can occur with a minimally scoped critical section, and design common functions to be reentrant.

5.4.3Stack/heap constraints and memory exhaustion/leaks

• On an embedded device, the stack (for function calls and local variables) and the heap (for dynamic allocation) are, unlike on a PC, extremely limited—often just a few KB to a few tens of KB. If the depth of recursive function calls, or the nesting of ISRs (multiple interrupts), grows deeper than expected, a stack overflow occurs (the stack region encroaches on other variable regions), leading to hard-to-diagnose undefined behavior or a crash.
• In a design that repeatedly uses dynamic memory allocation (e.g., malloc), forgetting to free allocated memory accumulates as a memory leak, and on an embedded device that runs for long periods, this eventually leads to memory exhaustion, where new allocations fail and functionality stops. For embedded devices premised on long-term unattended operation, designs that minimize dynamic allocation in favor of static allocation, or that rigorously audit allocate/free pairs, are emphasized.

5.4.4Section summary

• Keep the ISR to the bare minimum and defer time-consuming processing to normal processing. The longer it runs, the more other interrupts are masked, worsening real-time behavior
• Reentrant (not dependent on static/global variables) design of common functions, and a critical section (scoped to the minimum necessary) to protect shared variables, are the core of mutual exclusion
• With limited stack/heap resources, watch for stack overflow from excessive nesting depth, and memory exhaustion resulting from a memory leak caused by forgetting to free allocations