Hi
When I test Cortex-R52 with GIC500 (GICv3), I find an issue.
The interrupt is handled by the following order:
1. save context
2. read ICC_IAR0, get INTID
3. jump to ISR of the associated INTID
4. write ICC_EOIR0
5. restore context
The IRQ is unmasked before writing ICC_EOIR0.
When an IRQ is triggered frequently, I find the CPU will never goes to the last step - restore context. Could you explain the reason for that ?
BR, Grace
When you say it never goes to the last step, could you explain a little more? Is it taking some other kind of exception? Is it getting stuck on an instruction?
Note, I don't think you mean GIC-500. The Cortex-R52 has an integrated GICv3 interrupt controller, which I think is similar to GIC-500 but not the same.
Hi Martin
No other exception and the CPU does not get stuck. My set-up is as follows:
1. put a breakpoint at step 5, it never stops there
2. put a count variable to increment in the ISR, the variable is counting up all the time until to 536
3. put a breakpoint at step 2, at each time stop here, the stack address in the r13 decreases
4. as the stack address decreases all the time then overflows and overwrite other variables (the registered ISR address in the variable), so the count stops.
5. the interrupt is level triggered
I also do the comparing test:
If IRQ is masked before writing EOIR, the step 5 can be executed and the ISR stack never overflows.
If IRQ is unmasked before writing EOIR, the step 5 is not executed.
I think there must be some reason to mask the IRQ/FIQ before notify the end of interrupt by ICC_EOIR1/0.
Another question about IRQ and FIQ of GICv3:
if in the FIQ ISR, the IRQ is unmasked and an IRQ comes, will CPU service the IRQ first before writing ICC_EOIR0 to complete the FIQ service ?
Generally - yes. If the IRQ input is asserted and IRQs are unmasked (CPSR.I=0) then I'd expect the core to take the exception. That you're currently handling an FIQ (G0) interrupt doesn't really matter.