Hi,
I need to know what happens in the v7 architecture (TI Cortex R4) when both a data abort and FIQ are due to occur.
I found the following document which attempts to address this question but seems to contradict itself:
"The Data Abort has a higher priority than FIQ so that if both occur simultaneously the Data Abort mode is entered first, before immediately processing the FIQ exception. When the FIQ handler returns, it will return to the Data abort vector to handle the data abort."
ARM Information Center
It all makes sense until I read the last sentence which appears to state exactly the opposite of the previous sentence. Can you clear this up for me?
Thanks,
Ryan
Message was edited by: Ryan Smoots Added test information
The device technical reference manual ESM section records:
Group3 errors are reserved for high severity errors generated by diagnostics which have already generated a CPU abort response. Because an abort response in generated, there is no need to generate an interrupt response.
This statement answers my question in a round-about way by stating that the CPU abort response occurs before the FIQ. It appears that the originally posted information from the tech support ARM info center was just misleading.
Hello Ryan,
although I cannot have firm belief, I agree with you.
I interpret "When the FIQ handler returns" as "When the data abort occurs on the FIQ handler return". Isn't it proper?
Best regards,
Yasuhiko Koumoto.
Hi yasuhikokoumoto,
Thank you for your response. I am not sure what you mean by "When the data abort occurs on the FIQ handler return."
Hello,
I mean the stack pop or an interrupt return address might cause the data abort.
This is a subtle point and needs a careful explanation - let me try!
A Data Abort is a very important event and usually indicates that something serious has happened and that the OS needs to take some action. It is not an event which you want to miss. The trouble is that the ABORT signal from the memory system is only asserted for the duration of the aborting condition - it's not like an interrupt which usually stays asserted until you explicitly clear it. So, if you do not take the Data Abort exception immediately when the abort occurs, you will miss it and your system will potentially not be able to recover.
This means that the Data Abort exception has to have the highest priority of all exception (except Reset). But this may cause a problem with interrupt latency, specifically for FIQ which is often used for the most important interrupt in the system. Since Data Abort handlers are often very complex and can take a long time to execute, it would not be acceptable to delay the handling of an FIQ while executing the whole Data Abort handler.
The subtle thing to notice is that taking a Data Abort exception does _not_ disable FIQ. That means that when t he two occur together, the core will immediately take the Data Abort exception. However, as soon as it begins to execute the handler, the FIQ input is still asserted so it will break off the Data Abort handler and execute the FIQ handler first. Once the FIQ handler is complete, it will return to the Data Abort handler and run it to completion.
This mechanism ensures that both exceptions are taken, that the ABORT event is captured, that the effect on FIQ latency is minimised.
I hope that makes sense!
Chris
Thank you, Chris. This is exactly what I was looking for.