💾Embedded Systems Design Unit 7 – Interrupts and Exception Handling

What Are Interrupts and Exceptions?

• Interrupts are signals generated by hardware or software to indicate an event that requires immediate attention from the processor
• When an interrupt occurs, the processor suspends its current execution, saves its state, and transfers control to a special routine called an Interrupt Service Routine (ISR)
• Exceptions are similar to interrupts but are generated by the processor itself due to exceptional conditions such as division by zero, invalid memory access, or undefined instructions
• Interrupts and exceptions allow the processor to respond to critical events in a timely manner without constantly polling for their occurrence
• Embedded systems heavily rely on interrupts to handle real-time events, communicate with peripherals, and manage system resources efficiently
• Interrupts can be triggered by various sources such as timers, external devices, or software-generated events
• The processor determines the source of the interrupt using an interrupt vector table that maps each interrupt to its corresponding ISR

Types of Interrupts

• Maskable interrupts can be temporarily disabled or ignored by the processor using an interrupt mask register
  • Examples of maskable interrupts include peripheral interrupts, timer interrupts, and software interrupts
  • Masking interrupts allows critical sections of code to execute without interruption
• Non-maskable interrupts (NMIs) cannot be disabled and always require immediate attention from the processor
  • NMIs are used for critical events such as hardware failures, power loss, or watchdog timer timeouts
• Level-triggered interrupts remain active as long as the interrupt signal is asserted
  • The processor continuously services level-triggered interrupts until the interrupt source deasserts the signal
• Edge-triggered interrupts are detected by the processor on the rising or falling edge of the interrupt signal
  • Edge-triggered interrupts are serviced only once per edge transition, regardless of how long the signal remains active
• Software interrupts are generated by executing special instructions that trigger an interrupt
  • Software interrupts are used for inter-process communication, system calls, or to initiate context switches

Interrupt Service Routines (ISRs)

• ISRs are special functions that are executed when an interrupt occurs
• Each interrupt source has a dedicated ISR that handles the specific event
• ISRs have a higher priority than the main program and can preempt its execution
• The processor saves the context (register values, program counter, etc.) of the interrupted program before jumping to the ISR
• ISRs should be as short and fast as possible to minimize the time spent servicing the interrupt
  • Long or complex ISRs can affect the responsiveness of the system and delay the handling of other interrupts
• ISRs often have limited access to system resources and may need to use special mechanisms for communication and synchronization with the main program
• When an ISR completes, the processor restores the context of the interrupted program and resumes its execution from where it left off

Exception Handling Mechanisms

• Processors provide built-in exception handling mechanisms to detect and handle exceptional conditions
• When an exception occurs, the processor automatically invokes a corresponding exception handler
• Exception handlers are similar to ISRs but are triggered by the processor itself rather than external events
• Common exceptions include:
  • Division by zero
  • Invalid memory access (null pointer dereference, out-of-bounds access)
  • Undefined or illegal instructions
  • Page faults (in systems with virtual memory)
• Exception handlers can perform error recovery, graceful degradation, or simply log the error and halt the system
• In some cases, exceptions can be used to implement advanced features such as virtual memory, memory protection, or system calls
• Exception handling mechanisms vary across processors and may involve special registers, dedicated exception vectors, or software-based dispatch tables

Interrupt Priority and Nesting

• Interrupts can have different priorities to determine their relative importance and the order in which they are serviced
• Higher-priority interrupts can preempt the execution of lower-priority interrupts
• Interrupt nesting allows higher-priority interrupts to interrupt the execution of lower-priority ISRs
  • Nested interrupts can improve the responsiveness of the system to critical events
  • However, excessive nesting can lead to complex interrupt handling and potential stack overflow
• Processors often provide hardware support for interrupt prioritization and nesting through priority registers and automatic context saving
• Software-based prioritization can be achieved by manually disabling and enabling interrupts or using a priority-aware interrupt dispatcher
• Care must be taken to avoid priority inversion, where a high-priority task is blocked by a low-priority task holding a shared resource

Context Switching in Interrupts

• When an interrupt occurs, the processor needs to save the context of the currently executing program and switch to the ISR
• The context includes the values of registers, the program counter, and the processor status register
• The processor typically uses a dedicated stack to save the context during an interrupt
  • The interrupt stack is separate from the main program stack to avoid corruption and ensure a clean context switch
• After saving the context, the processor updates the program counter to the address of the ISR and begins executing it
• When the ISR completes, the processor restores the saved context from the stack and resumes the interrupted program
• Context switching overhead can impact the performance and responsiveness of the system
  • Minimizing the number of registers saved and optimizing the context switch code can help reduce the overhead
• In systems with multiple threads or processes, context switching may also involve updating memory management units, flushing caches, or managing other thread-specific resources

Interrupt Latency and Response Time

• Interrupt latency is the time between the occurrence of an interrupt and the start of the ISR execution
  • Latency can be affected by factors such as interrupt prioritization, context switching overhead, and processor architecture
• Response time is the time between the occurrence of an interrupt and the completion of the ISR
  • Response time includes both the interrupt latency and the execution time of the ISR itself
• Minimizing interrupt latency and response time is crucial for real-time embedded systems that require prompt reactions to events
• Techniques to reduce latency and improve response time include:
  • Using hardware-based prioritization and nesting
  • Optimizing ISR code to minimize execution time
  • Avoiding long or blocking operations within ISRs
  • Using dedicated hardware for time-critical tasks
• Interrupt latency and response time can be measured using specialized hardware timers or software profiling tools
• Analyzing and optimizing interrupt performance is an important aspect of embedded systems design, especially for applications with strict timing requirements

Best Practices for Interrupt-Driven Design

• Keep ISRs short and fast to minimize the time spent in interrupt context
  • Defer non-critical processing to the main program or lower-priority tasks
• Avoid using blocking operations or busy-waiting within ISRs
  • Use asynchronous techniques such as flags, semaphores, or message queues for communication and synchronization
• Minimize the use of shared resources within ISRs to avoid resource contention and priority inversion
  • If shared resources are necessary, use proper synchronization mechanisms such as mutexes or spinlocks
• Use a consistent and well-defined naming convention for ISRs and interrupt-related variables
  • Clear and descriptive names can improve code readability and maintainability
• Properly configure and initialize interrupt-related hardware registers and settings
  • Incorrect configurations can lead to unexpected behavior or system instability
• Test and validate interrupt handling code thoroughly, including edge cases and error conditions
  • Use techniques such as fault injection or simulation to verify the robustness of the interrupt-driven design
• Document the interrupt handling logic, priorities, and dependencies clearly
  • Proper documentation can facilitate code maintenance, debugging, and future enhancements
• Consider the trade-offs between interrupt-driven and polling-based approaches based on the specific requirements of the system
  • Polling may be sufficient for low-frequency events or simple systems, while interrupts are better suited for real-time and event-driven scenarios