Unexpected FIQ Source in ARM AArch64: Tracing and Debugging Guide

ARM Cortex-A FIQ Exception at EL3 Without External Interrupt Signal

When working with ARM Cortex-A processors in AArch64 mode, encountering an unexpected Fast Interrupt Request (FIQ) can be a challenging issue to debug, especially when no external interrupt signal is asserted. In this scenario, the Program Counter (PC) jumps to the FIQ vector table entry at offset 0x300, indicating that the processor has taken an FIQ exception. However, the absence of an external interrupt signal raises questions about the source of the FIQ. This issue is particularly critical when operating at Exception Level 3 (EL3), as FIQs at this level are typically used for secure monitor calls or critical system events.

The primary concern is identifying the root cause of the FIQ. Is it due to an internal hardware condition, a software misconfiguration, or an instruction error? Additionally, while masking the FIQ using the DAIF bits in the PSTATE register (specifically DAIF[1:0] set to 2’b11) can suppress the exception, this is not a solution but rather a temporary workaround. The goal is to trace the FIQ source and resolve the underlying issue.

Potential Causes: ELR_ELx, SPSR_ELx, ISR_EL1, and GIC Configuration

To diagnose the unexpected FIQ, several hardware and software components must be examined. The first step is to inspect the Exception Link Register (ELR_ELx) and the Saved Program Status Register (SPSR_ELx) for the current Exception Level (ELx). These registers provide critical information about the state of the processor before the FIQ was taken. ELR_ELx holds the return address, which can help identify the instruction or code segment that led to the FIQ. SPSR_ELx contains the processor state, including the condition flags, interrupt masks, and execution mode, which can reveal whether the FIQ was triggered due to a specific condition or state.

Next, the Interrupt Status Register (ISR_EL1) should be checked to determine if the FIQ input is being asserted internally. This register provides a snapshot of the interrupt state, confirming whether the FIQ signal is active. If the FIQ is not asserted, the issue may lie elsewhere, such as in the Generic Interrupt Controller (GIC) configuration or an internal processor condition.

The GIC plays a central role in managing interrupts in ARM systems. The Interrupt Controller CPU Interface registers, specifically ICC_HPPIR0_EL1 and ICC_HPPIR1_EL1, should be examined to identify which interrupt the GIC is signaling. These registers indicate the highest priority pending interrupt, which can help trace the FIQ source. If the GIC is configured incorrectly or if there is a mismatch between the interrupt source and the FIQ routing, this could lead to unexpected behavior.

Another potential cause is the misconfiguration of the interrupt routing tables or the Secure Configuration Register (SCR_EL3). In AArch64, the SCR_EL3 register controls whether FIQs are routed to EL3 or lower exception levels. If the FIQ is incorrectly routed to EL3, it could result in an unexpected exception. Additionally, the GIC Distributor and Redistributor registers should be reviewed to ensure that the interrupt priorities, targets, and enable states are correctly configured.

Debugging Steps: Analyzing ELR_ELx, SPSR_ELx, ISR_EL1, and GIC Registers

To systematically trace the unexpected FIQ source, follow these debugging steps:

1. Inspect ELR_ELx and SPSR_ELx: Begin by reading the ELR_ELx and SPSR_ELx registers for the current Exception Level. ELR_ELx will provide the address of the instruction that was executing when the FIQ was taken. This address can be cross-referenced with the disassembled code to identify the specific instruction or function that may have triggered the FIQ. SPSR_ELx will reveal the processor state, including the interrupt masks, execution mode, and condition flags. If the FIQ was taken due to a specific condition, such as an overflow or alignment fault, this will be reflected in the SPSR_ELx.

2. Check ISR_EL1: Read the ISR_EL1 register to determine if the FIQ input is being asserted. If the FIQ signal is not active, this suggests that the FIQ may have been triggered by an internal condition rather than an external interrupt. In this case, the focus should shift to examining the processor’s internal state and configuration.

3. Examine ICC_HPPIR0_EL1 and ICC_HPPIR1_EL1: These registers indicate the highest priority pending interrupt in the GIC. If the FIQ is being signaled by the GIC, these registers will provide the interrupt ID, which can be used to trace the source. Compare the interrupt ID with the GIC configuration to ensure that the interrupt is correctly mapped to the FIQ.

4. Review GIC Configuration: Verify the GIC Distributor and Redistributor registers to ensure that the interrupt priorities, targets, and enable states are correctly configured. Pay particular attention to the GICD_CTLR and GICR_WAKER registers, which control the overall operation of the GIC. If the GIC is not enabled or if the interrupts are not correctly routed, this could lead to unexpected FIQs.

5. Check SCR_EL3 and Interrupt Routing: Ensure that the SCR_EL3 register is correctly configured to route FIQs to the appropriate Exception Level. If FIQs are incorrectly routed to EL3, this could result in unexpected exceptions. Additionally, review the interrupt routing tables to ensure that the FIQ is correctly mapped to the intended source.

6. Analyze Processor Internal State: If the FIQ is not being signaled by the GIC or an external interrupt, the issue may lie in the processor’s internal state. Check the processor’s internal registers, such as the Fault Status Registers (FSR) and Fault Address Registers (FAR), to identify any internal faults or conditions that may have triggered the FIQ.

7. Verify Software Configuration: Review the software configuration, including the interrupt handlers and exception vectors, to ensure that they are correctly implemented. If the FIQ handler is not correctly configured, this could lead to unexpected behavior. Additionally, check for any software bugs or misconfigurations that may have caused the FIQ.

8. Use Debugging Tools: Utilize debugging tools, such as JTAG or trace probes, to capture the processor’s state and execution flow leading up to the FIQ. These tools can provide valuable insights into the sequence of events that led to the exception.

By following these steps, you can systematically trace the source of the unexpected FIQ and identify the root cause. Whether the issue lies in the hardware configuration, software implementation, or an internal processor condition, a thorough and methodical approach will help resolve the problem and ensure reliable system operation.