multiple load in interrupts: any restrictions?

[flyer31]

Posted on January 13, 2012 at 11:42

Concerning the NVIC interrupt handler: I am a bit curious, how NVIC manages to keep log of the multi-load commands, if several interrupts would interrupt one each other. As far as I understand it, STM32 has 16 levels of priority. So in worst case, if I would use 16 interrupt with different priorities, and they come all just duing a multi-load command of a lower interrupt, at the end there would be 16 ''hanging'' multi-load commands. Is this really possible, or is there some maximum limit for this ''multi-load-stack''? (or should I avoid to use multi-load in interrupt routines?)

[Tesla DeLorean]

Posted on January 13, 2012 at 13:22

Each interrupt source latches it's state and drives the NVIC, and that has to be cleared at the source for it to go away.

That interrupt source translates into a 4-bit field. You control the grouping The NVIC has a precedence tree logic structure that identifies the inputs priority, both in terms of the 4-bit value, and the size of the interrupt number. Each time you exit the interrupt routine it re-evaluates what's pending. Preempting will occur if the arriving source flags that. Yes, if you use load/store multiple you will increase interrupt latency. Yes, if you get a bunch of pre-empting interrupts with increasing priority in just the right sequence you could end up with your worst case prediction. Sounds improbable. A source with a low priority may never get serviced if the processor is saturated with higher priority requests. Best to get a mix of Pre-emption and Sub-Priority. Multiple sources can share the same 4-bit value, bin them based on the urgency they have. Have critical service windows, use DMA or HW if possible. Load/Store multiple will not block DMA. Defer as much busy-work as possible outside the interrupt service routine. The NVIC knows nothing about Load/Store multiple, the Core doesn't check the singular interrupt pending flag (preempt) from the NVIC until each instruction completes. ie the Load/Store multiple is atomic

[disirio2]

Posted on January 13, 2012 at 14:17

Hi,

There are no restrictions, the multiple load/store can be interrupted without added latency, the status of the interrupted multiple load/store is saved into the exception context inside a dedicated field of the status register (EPSR) so it takes no extra space in the main exception stack. On exception return the instruction is resumed where interrupted. This applies to the CM3 and CM4 but not to the CM0, CM0 multiple load/store cannot be interrupted and add latency to interrupts. Giovanni ---

http://www.chibios.org

[Tesla DeLorean]

Posted on January 13, 2012 at 17:02

Is the interrupt stack frame generation interuptable?

[Danish1]

Posted on January 13, 2012 at 21:10

I don't think interrupt-stack-frame-generation is interruptable.

But I have to ask: Why should it be interruptable? Stack-frame-generation is about saving the _current_ (executing) state. The processor only starts executing interrupt code after the entire state has been saved onto the stack. And the Arm Cortex processor knows about this, so it only decides _which_ interrupt code to execute once the state is saved. So if a low-priority interrupt is what caused execution of the main code to stop, but a higher-priority interrupt happens during the saving of the state for that low-priority interrupt, the processor does not need to do a second context-save. It can start executing the higher-priority interrupt as soon as the original context-save is complete (with faster-than-expected latency). On the other hand, if the higher-priority interrupt came along once the low-priority interrupt had started executing, a second context-save would be put onto the stack. Regards, Danish

[disirio2]

Posted on January 13, 2012 at 21:16

There is no need to interrupt stacking, if a stack frame is being created and an higher priority interrupt becomes active then it is served first (late arrival mechanism), the interrupt that originally triggered the save is served next without creating another frame (tail chaining).

Giovanni ---

http://www.chibios.org

[Tesla DeLorean]

Posted on January 13, 2012 at 22:22

I don't think interrupt-stack-frame-generation is interruptable.

But I have to ask: Why should it be interruptable?

Stack-frame-generation is about saving the _current_ (executing) state. The question was somewhat rhetorical. According to one of the presentations it makes the vectoring decision after it has stacked the current state. http://www.arm.com/files/pdf/IntroToCortex-M3.pdf

[joseph239955_st]

Posted on January 14, 2012 at 00:10

Hi there,

As Giovanni mentioned, the status of multiple load/store is saved in the stacked EPSR (part of the xPSR). So when the interrupt returns, it can resume from the interrupted transfer. For Cortex-M0, if a interrupt take place during a multiple-load/store instruction, the load/store is stopped and the interrupt is serviced. When the interrupt returned, the whole multiple load/store instruction is restarted from the first transfer.  Therefore, do not use multiple load/store instructions on FIFO registers as the read/write could happen twice. Giovanni  is also correct that when a higher priority interrupt takes place during stacking, the stacking continue but the vector fetch will get the higher priority interrupt (late arrivial). So there is no need to interrupt a stack frame generation. regards, Joseph

[Tesla DeLorean]

Posted on January 14, 2012 at 01:23

What about integer and floating point divides?

Writing to Flash can cause significant delays if you try to read/execute from it.

[joseph239955_st]

Posted on January 14, 2012 at 22:28

Hi Clive,

For divide instructions, the operation would be terminated and restart after the interrupt handling is completed.If you have a memory accesses that takes long time, the processor will have to wait because the transfer will have to be completed first before processor's bus interface can start the stacking process (during the interrupt handling sequence).regards,Joseph