With Cortex-R5F, we have a case where a read to the L2 memory generates both a synchronous data abort and an FIQ with near-zero delay. We are reading from RAM while the RAM is in test mode and corrupts the parity of the read command. The effect is that we are only seeing the FIQ. This is also true if with the debugger we put a HW breakpoint on both the data abort and the FIQ handlers: only the FIQ handler breakpoint is reached.
I would like to understand why that is what we are seeing. I am a bit surprised that the FIQ is as fast as the abort; indeed, the FIQ goes through multiple components, including an interrupt controller.
What we would like to know is:if the processor is ready to take simultaneously a synchronous data abort and an unmasked FIQ, to which does it give priority?
ARMv7-A/R Architecture Reference Manual §B1.8.2 "Exception priority order" -> "Architectural requirements for taking asynchronous exceptions" says:
"Within these limits, the prioritization of asynchronous exceptions relative to other exceptions, both synchronous and asynchronous, is IMPLEMENTATION DEFINED."
Meaning that the information is to be found in the Cortex-R5 Technical Reference Manual. However, I can't find it...
Thanks for your help.
What kind of access by the core triggers the abort? (e.g. Device type data access, instruction fetch...) Are you sure it's synchronous (from the processor's perspective)?
What address (taking into account the required LR adjustment) is reported in LR_fiq? Is that the instruction that triggers the abort, or the one after it?
It is a read to Normal memory that makes the error. Yes, it is synchronous since the DFSR reports Synchronous External Abort. LR-fiq gives 0x13C2 to which I need to subtract 4 accord to Cortex-R5 TRM,so 0x13BE which points to the instruction doing the load.
But my question is: which of sync data abort or FIQ will the core handle first if they occur at the same time? What's their relative priority?
In practice it is incredibly difficult to generate both at precisely the same time, even if they are caused by the same action. The reason being that the FIQ is asynchronous. The signal travels via an interrupt controller, which will introduce it's own timing/latency effects.
The LR value you see is interesting. If I understood you correctly, the FIQ is reporting a return address of the LDR that triggers the error. Meaning that the as far as the FIQ handler is concerned, the LDR hasn't happened yet (the return address is the first instruction which *wasn't* executed before the interrupt).
I think what is happening is that the processor starts the load early (before the LDR is committed) - which would count as speculative. Something it is allowed to do if the address is marked as Normal. The sync abort on the LDR won't/can't happen until the LDR is committed. But FIQ can be taken immediately (well, on an instruction boundary anyway).
Therefore... if the FIQ can make it to the processor before the LDR becomes committed, you can see the FIQ taken *first*. Because the FIQ is taken, the access that triggered it remains speculative, as from the processor's perspective the LDR that required never committed. I am somewhat surprised that the FIQ could make to the processor fast enough, but it seems to fit your description.
Thanks for this clear and complete answer!
View all questions in Cortex-R / R-Profile forum