• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Subscribers 349 subscribers
  • Views 5956 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Testing for interrupt

Upp3r Upp3r
Note: This was originally posted on 19th November 2008 at http://forums.arm.com

Im looking for a way to test if there is an interrupt currently processing on my ARM7. I can see that the interrupt disable bits are set to disable the FIQ and IRQ interrupts, but are they set when an interrupt is triggered? In my "TMS470R1x User's Guide" in the section on Exceptions, it gives a run down when an exception occurs and it says it "may also set interrupt disable flags" but nothing decisive.
My question is:  Do the CPSR I and F bits  signify there is an interrupt in progress, i.e, when an interrupt occurs, is the disable flag set? If not, how could I determine if there is an interrupt in progress?
  • 0
    Note: This was originally posted on 20th November 2008 at http://forums.arm.com

    When the interrupt occurs (nIRQ and nFIQ), the flags of the CPSR was set (disable).
    So you don't worry about it.
  • +1 Arm Employee Badge
    Note: This was originally posted on 20th November 2008 at http://forums.arm.com

    The CPSR I and F bits do not indicate that an interrupt is in progress. They do nothing other than enable or disable interrupts. However, a side effect of an interrupt being triggered is that the respective CPSR bit will be set* in order to prevent the same interrupt to occur again. If this didn't happen, the LR could be corrupted before it can be stacked and it would be practically impossible to build a robust system. Nested interrupts are possible, but you need to fiddle about somewhat in order to make them work as expected.

    * In addition, an FIQ will cause IRQs to be disabled as FIQs are intended to be high-priority fast interrupts for time-critical events.

    Note, however, that each mode has its own SPSR, and it is usual to copy this SPSR to the CPSR before returning from the interrupt. Doing this will restore the I and F bits (along with the processor mode) to whatever they were before the interrupt was triggered.

    Also, check that you know what you mean when you say "an interrupt currently processing". It is rare that the code itself needs to check if it's running in interrupt context as the program flow automatically branches to the exception handler. It's more likely that you'd need to check this from a debugger, but even then the interrupt code is almost always different from the main program code. Why do you need to determine if there is an interrupt in progress, and from what context do you need to perform this check?