ARM Cortex-R52 GICv3 Interrupt Handling Issue with ICC_EOIR and Stack Overflow

Cortex-R52 GICv3 Interrupt Handling Sequence and Stack Overflow

The Cortex-R52 processor, when paired with a GICv3 interrupt controller, can experience a critical issue during interrupt handling where the processor fails to restore the context after handling an interrupt. This issue manifests when interrupts are triggered frequently, and the IRQ is unmasked before writing to the ICC_EOIR0 register. The observed behavior is that the processor never reaches the context restoration step, leading to a continuous increment of the stack pointer and eventual stack overflow. This overflow corrupts other variables, including the registered ISR address, causing the system to halt.

The interrupt handling sequence in question is as follows:

1. Save context.
2. Read ICC_IAR0 to get the INTID.
3. Jump to the ISR associated with the INTID.
4. Write to ICC_EOIR0.
5. Restore context.

When the IRQ is unmasked before writing to ICC_EOIR0, the processor gets stuck in a loop where it continuously handles the interrupt without restoring the context. This results in the stack pointer decrementing with each interrupt, eventually leading to a stack overflow. The overflow corrupts critical data, including the ISR address, causing the system to fail.

IRQ Unmasking Before ICC_EOIR0 and Priority Preemption

The root cause of this issue lies in the timing of IRQ unmasking relative to the write to ICC_EOIR0. When the IRQ is unmasked before writing to ICC_EOIR0, the processor can immediately take a new interrupt before completing the current one. This leads to a situation where the processor is continuously handling new interrupts without ever restoring the context of the previous ones. The stack pointer keeps decrementing, leading to a stack overflow.

Additionally, the issue is exacerbated by the priority preemption mechanism of the GICv3. If a higher-priority interrupt arrives while the processor is handling a lower-priority one, the processor will preempt the current ISR and handle the higher-priority interrupt. However, if the IRQ is unmasked before writing to ICC_EOIR0, the processor may not correctly handle the priority preemption, leading to the observed behavior.

The problem is further complicated by the fact that the Cortex-R52’s integrated GICv3 interrupt controller may behave differently from standalone GIC-500 implementations. The integrated GICv3 in the Cortex-R52 may have specific timing requirements or behaviors that are not immediately apparent, leading to subtle issues like the one described.

Implementing Proper Interrupt Masking and Context Management

To resolve this issue, it is crucial to ensure that interrupts are masked before writing to ICC_EOIR0 and only unmasked after the context has been restored. This prevents the processor from taking a new interrupt before completing the current one, ensuring that the context is correctly restored and the stack pointer is properly managed.

The following steps outline the proper handling of interrupts in this scenario:

1. Save Context: Upon entering the ISR, save the processor’s context, including the stack pointer, registers, and any other critical state information.

2. Read ICC_IAR0: Read the ICC_IAR0 register to get the INTID of the interrupt being handled. This acknowledges the interrupt and allows the GICv3 to prioritize subsequent interrupts correctly.

3. Jump to ISR: Jump to the ISR associated with the INTID. The ISR should handle the interrupt as quickly as possible to minimize latency.

4. Mask Interrupts: Before writing to ICC_EOIR0, mask the IRQ to prevent the processor from taking a new interrupt before completing the current one. This can be done by setting the CPSR.I bit.

5. Write to ICC_EOIR0: Write to the ICC_EOIR0 register to signal the end of the interrupt handling. This allows the GICv3 to deactivate the interrupt and update its internal state.

6. Restore Context: After writing to ICC_EOIR0, restore the processor’s context, including the stack pointer and registers. This ensures that the processor is in the correct state to continue execution.

7. Unmask Interrupts: Finally, unmask the IRQ by clearing the CPSR.I bit. This allows the processor to take new interrupts.

By following these steps, the processor will correctly handle interrupts without getting stuck in a loop or causing a stack overflow. This approach ensures that the context is properly managed and that the GICv3’s priority preemption mechanism works as intended.

Additionally, it is important to consider the priority levels of interrupts and how they interact with the GICv3’s preemption mechanism. If a higher-priority interrupt arrives while the processor is handling a lower-priority one, the processor should preempt the current ISR and handle the higher-priority interrupt. However, this preemption should only occur if the IRQ is unmasked after the context has been restored. This ensures that the processor can correctly handle nested interrupts without causing a stack overflow or other issues.

In summary, the key to resolving this issue is proper interrupt masking and context management. By ensuring that interrupts are masked before writing to ICC_EOIR0 and only unmasked after the context has been restored, the processor can correctly handle interrupts without getting stuck in a loop or causing a stack overflow. This approach ensures that the GICv3’s priority preemption mechanism works as intended and that the system remains stable even under heavy interrupt load.