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

Abort some questions of arm interrupt

Note: This was originally posted on 20th June 2008 at http://forums.arm.com

I try to understand arm interrupt,there are some questions I don't know,
1.   Why the nested interrupt has to switch out of irq mode to svc mode? I think it only pushes the r14_irq into the irq stack.
   2.    The basic difference between a reentrant interrupt handler and a nested interrupt han-dler is that the interrupts are reenabled early on in the reentrant interrupt handler, which can reduce interrupt latency.
    I can't understand that ?

   thanks!

Parents

0 Simon Craske over 12 years ago

Note: This was originally posted on 25th June 2008 at http://forums.arm.com

Sean,

For clarity, the definitions I use are as follows;

Interrupt nesting: interrupt A can preempt handling of interrupt B; both interrupt A and interrupt B's handlers can be "active" at the same time.

Re-entrant interrupt: interrupt A can preempt handling of interrupt A; interrupt A's handler can be active concurrently with itself.

Interrupt chaining: (an overloaded term) means one of two things; firstly checking for a new pending interrupt before returning from interupt context (i.e. a scenario which would could waste time by unstacking and then straight away restacking the same registers); or secondly, linking handlers together (typically by replacing the interrupt vector with the new handler to run, followed by the new handler calling the original handler). I assume you mean the first.

Interrupt nesting on ARM7 typically requires some degree of re-entrancy (ignoring FIQ vs IRQ) due to all handlers hanging off the IRQ vector. Cortex-M3 has greater flexibility in interrupt handling, priorities and number of vectors, so the ability/requirement for re-entrancy is signficiantly less.

Re-entrancy on ARM7 requires code to exit from the "true" interrupt context and to drop priority, i.e. switch out of IRQ mode, and re-enable interrupts via a small code stub; the same is true for Cortex-M3. Unlike ARM7, the same isn't true for interrupt nesting (ignoring FIQ), if the priority of A is higher than the currently running interrupt B, then A will preempt automatically on Cortex-M3.

Implementing re-entrancy on Cortex-M3 requires, as I eluded to earlier, the pushing of a thread stack frame containing the ReturnPC of the re-entrant interrupt handler, a suitable Thread xPSR and some initial register values onto the stack, followed by performing an interrupt return to Thread mode. Whilst this part of the code clearly isn't re-entrant, the part "returned" to is. Exiting from a re-entrant handler written like this is less trivial - and left as an exercise for the reader :-)

hth
s.
Cancel
Vote up 0 Vote down

Cancel

Reply

0 Simon Craske over 12 years ago

Note: This was originally posted on 25th June 2008 at http://forums.arm.com

Sean,

For clarity, the definitions I use are as follows;

Interrupt nesting: interrupt A can preempt handling of interrupt B; both interrupt A and interrupt B's handlers can be "active" at the same time.

Re-entrant interrupt: interrupt A can preempt handling of interrupt A; interrupt A's handler can be active concurrently with itself.

Interrupt chaining: (an overloaded term) means one of two things; firstly checking for a new pending interrupt before returning from interupt context (i.e. a scenario which would could waste time by unstacking and then straight away restacking the same registers); or secondly, linking handlers together (typically by replacing the interrupt vector with the new handler to run, followed by the new handler calling the original handler). I assume you mean the first.

Interrupt nesting on ARM7 typically requires some degree of re-entrancy (ignoring FIQ vs IRQ) due to all handlers hanging off the IRQ vector. Cortex-M3 has greater flexibility in interrupt handling, priorities and number of vectors, so the ability/requirement for re-entrancy is signficiantly less.

Re-entrancy on ARM7 requires code to exit from the "true" interrupt context and to drop priority, i.e. switch out of IRQ mode, and re-enable interrupts via a small code stub; the same is true for Cortex-M3. Unlike ARM7, the same isn't true for interrupt nesting (ignoring FIQ), if the priority of A is higher than the currently running interrupt B, then A will preempt automatically on Cortex-M3.

Implementing re-entrancy on Cortex-M3 requires, as I eluded to earlier, the pushing of a thread stack frame containing the ReturnPC of the re-entrant interrupt handler, a suitable Thread xPSR and some initial register values onto the stack, followed by performing an interrupt return to Thread mode. Whilst this part of the code clearly isn't re-entrant, the part "returned" to is. Exiting from a re-entrant handler written like this is less trivial - and left as an exercise for the reader :-)

hth
s.
Cancel
Vote up 0 Vote down

Cancel

Children

No data