Exception priority behavior

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

Parents
  • Hi,

    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

Reply
  • Hi,

    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

Children