Exception Handling and Interrupt Preemption in ARM Cortex-A53

Exception Handler Execution and Interrupt Responsiveness

When an ARM Cortex-A53 processor enters an exception handler, the system’s ability to respond to hardware interrupts depends on the priority of the exception and the configuration of the interrupt controller. Exceptions such as Data Abort, Undefined Instruction, or Prefetch Abort are classified as synchronous exceptions and are typically higher priority than asynchronous interrupts like those from peripherals (e.g., UART). The ARM architecture defines a strict priority hierarchy for exceptions and interrupts, which determines whether an interrupt can preempt an ongoing exception handler.

In the context of the Cortex-A53, exceptions are handled by the processor’s exception vector table, which maps specific exception types to their respective handlers. When an exception occurs, the processor saves the current state (including the Program Counter and CPSR) and branches to the corresponding exception handler. During this time, the processor may mask lower-priority interrupts, depending on the exception type and the configuration of the interrupt controller (e.g., GIC-400).

For example, if a Data Abort exception occurs, the processor will enter the Data Abort handler. If a UART interrupt is generated while the processor is executing the Data Abort handler, the UART interrupt will not preempt the Data Abort handler unless the UART interrupt is configured as a higher-priority Fast Interrupt Request (FIQ). In most cases, IRQs (Interrupt Requests) are lower priority than synchronous exceptions, meaning the UART ISR will not be invoked until the Data Abort handler completes.

However, the ability to service interrupts during exception handling can be influenced by software configuration. For instance, the CPSR (Current Program Status Register) contains interrupt mask bits (I and F) that can be modified within the exception handler to enable or disable IRQ and FIQ handling. If the exception handler explicitly enables IRQs by clearing the I bit, lower-priority interrupts like the UART IRQ can preempt the exception handler. This approach requires careful consideration to avoid race conditions or stack overflow due to nested exceptions.

Priority Hierarchy and Interrupt Masking in ARM Cortex-A53

The ARM Cortex-A53 processor implements a priority-based exception handling mechanism, where exceptions and interrupts are categorized into distinct priority levels. The priority hierarchy, from highest to lowest, is as follows:

1. Reset: The highest-priority exception, triggered by a system reset.
2. Data Abort: Occurs when a memory access fails (e.g., due to a page fault or invalid address).
3. Prefetch Abort: Occurs when an instruction fetch fails.
4. Undefined Instruction: Triggered when the processor encounters an unrecognized instruction.
5. Fast Interrupt Request (FIQ): A high-priority interrupt used for time-critical tasks.
6. Interrupt Request (IRQ): A general-purpose interrupt used for peripheral communication.
7. Supervisor Call (SVC): Used for system calls or software-generated exceptions.

The priority hierarchy ensures that higher-priority exceptions preempt lower-priority ones. For example, a Data Abort exception will preempt an ongoing IRQ handler, but an IRQ cannot preempt a Data Abort handler unless the IRQ is configured as an FIQ.

Interrupt masking plays a critical role in determining whether an interrupt can preempt an exception handler. The CPSR contains two bits that control interrupt masking:

• I bit: Masks IRQ interrupts when set to 1.
• F bit: Masks FIQ interrupts when set to 1.

When an exception occurs, the processor automatically sets the appropriate mask bits to prevent lower-priority interrupts from preempting the exception handler. For example, when a Data Abort exception occurs, the processor sets the I bit to mask IRQs. If the exception handler needs to allow IRQs, it must explicitly clear the I bit using an instruction like CPSIE I.

In the case of UART interrupts, the UART peripheral typically generates an IRQ. If the processor is executing a Data Abort handler with IRQs masked, the UART interrupt will remain pending until the Data Abort handler completes and the I bit is cleared. If the UART interrupt is configured as an FIQ, it may preempt the Data Abort handler, provided the F bit is not set.

Debugging and Recovery Strategies for Exception Handlers

To recover a board that lands in an exception handler and send register/state information via UART, the following strategies can be employed:

1. Direct UART Access in Exception Handler: Instead of relying on the UART ISR, the exception handler can directly access the UART registers to transmit debug information. This approach avoids the need for interrupt preemption and ensures that the UART communication is handled within the exception context. For example, the Data Abort handler can write to the UART Transmit Holding Register (THR) to send debug messages to the console.

2. Interrupt Mask Management: If the exception handler needs to service UART interrupts, it can selectively enable IRQs by clearing the I bit in the CPSR. This allows the UART ISR to preempt the exception handler and process incoming data. However, this approach requires careful handling to avoid nested exceptions and stack overflow. The exception handler should save the current state before enabling interrupts and restore it afterward.

3. Polling UART Status: In scenarios where interrupt preemption is not feasible, the exception handler can poll the UART Line Status Register (LSR) to check for incoming data. This approach avoids the need for interrupt handling but may introduce latency in processing UART data.

4. Exception Handler Chaining: For complex recovery scenarios, the exception handler can chain to a secondary handler that manages UART communication. The primary handler saves the processor state and transfers control to the secondary handler, which can enable interrupts and handle UART communication independently.

5. Debugger Integration: If the system supports a debugger (e.g., via JTAG), the exception handler can trigger a breakpoint and transfer control to the debugger. The debugger can then extract the processor state and transmit it via UART or another interface.

Below is a table summarizing the key considerations for each strategy:

By carefully selecting and implementing these strategies, developers can ensure robust exception handling and recovery in ARM Cortex-A53-based systems.