Hello
I met an issue of FIQ interrupt1023 occurred when two periodic interrupts existed: vector270: priority: 12, group1 (IRQ) and vector27: priority 16, group0 (FIQ).
When the fiq_exception got the INTID1023, I saw that ICC_HPPIR0: 0x1B (27), ICC_AP1R0: 0x1000 (active priority: 12). As the irq_exception will not mask FIQ, I suppose that when the CPU is handling vector270 (IRQ), vector27 (FIQ) comes and interrupts it. But as the priority of vector27 is lower than vector270, interrupt1023 is reported due to no sufficient priority. Is my understanding right ?
If so, what are the recommendations for irq and fiq handling when the system have both IRQ and FIQ interrupts enabled ?
BR, Grace
Hi Martin
I think your assumption is right because I saw ICC_HPPI1 = 0x10E (270) before read of IAR0.
Martin Weidmann said:If the handler then returned, I'd expect the core to take an IRQ exception pretty immediately (assuming PSTATE.I=0) and then you'd handle that. Once the G1 interrupt is priority dropped (ICC_EOIR1), the GIC will be able to select the original G0 interrupt as the HPPI again.
Currently, for the FIQ1023, the CPU will do nothing but stop there. Are you saying that I can make the CPU complete the fiq exception handling after entered vector1023. Then it will go to handle IRQ normally.
If so, what's the safe handling for INT1023 ?
1023 isn't a "real" INTID, it's a reserved value meaning either there is no HPPI or the current HPPI is not acknowledgeable via this register. It's there to stop you accidentally ack'ing an FIQ in the IRQ handler or vice versa
What does CPU need to do for INTID1023 ? only while() in the handler to stop the CPU there ? or save some status and then go back to the main program ?
1023 means you didn't ack an interrupt. Under "normal" operation it's possible to get this, so IRQ/FIQ handlers should be written to cope with it. Typically what I'd expect is that the hander would just return (after clearing up any corrupted registers/stacks/etc). You didn't ack an interrupt, therefore the is nothing for the handler to do.
If you were repeatedly taking an interrupt, then getting 1023 back from the IARs, that would be unusual and worth investigating. So you might do some sort of logging to check if it's happening a lot.