ARM cancel execution of pre-empted interrupts

Question

I can't seem to find an answer to this in google or the Definitive guide...

Is it possible to from one interrupt, cancel the return to any pre-empted interrupts? For example, I have an ISR which is called when an interrupt driven process needs to be aborted. Presumably, I will have been in an ISR when this interrupt is triggered, so I would like to reset the state of my state machine and cancel the completion of the previous state processing since there was an error. I know I could set a volatile flag but then I would need to check it constantly in the normal process code. I would prefer a much more direct, deterministic way to cancel the pre-empted interrupt.

Additional Information from the comments

I have a 2 processor system with an SPI command/control bus. The slave waits for a command from the master, then executes it and sends a response back. This is driven with some handshaking signals since the STM32F4 series has a useless hardware CS design. The problem I am experiencing from my other question is that after some time, the data returned to the master from a command is complete nonsense (specifically the last value received by the slave x transfer length). The master is able to detect this error and sends an abort signal. When received, I want the slave to cancel its DMA/SPI transfer, and return its state machine to waiting for a command. I can accomplish resetting the state machine no problem, I just want to make sure that when the abort ISR exits, it does not return to continue a DMA or USB ISR which is no longer valid.

Answer 1

I am concerned that the question implies that the there is something complicated inside the system. That complication might make this even more difficult than it sounds!

I recommend trying Mishyoshi's answer first. It focuses on a cleaner, less intricate, easier to build and test solution.

However, I'll try to give an overview of the way 'aborting' and interrupt service routine might be done, so that folks can judge for themselves.

From a purely technical perspective, it is possible to 'abort' an 'outer' interrupt service routine (ISR) which itself was interrupted to reach 'this' 'inner' interrupt service routine in specific cases, for embedded (Cortex-M processors). However it is a bit tricky, maybe very hard to debug and make robust, and will need some good assembler and hardware debug skills.

A 'simple' technique relies on the 'outer' ISR never ever, under any circumstances calling any functions. If that is not a feasible guarantee then it gets much harder. Put another way, this will work if and only if the 'inner' ISR is always and only called while executing code within the body of the 'outer' ISR, and never in a function called by the 'outer; ISR

It will also get more complex if there are two processor stacks. It is still feasible, but more tricky.

Background:
An ARM does not store the return address of the current running function or ISR on the stack.

That return address is stored in the link register called 'lr' or R14. The only way to update the LR register is with assembler. IIRC might not be as easy as it sounds as some compilers will reload LR after your inline assembler has done its business, or maybe whine.

The return address for the outer function or ISR is on the stack somewhere. Finding that and loading it into the LR will do some of the work to abort the 'outer' ISR when the inner ISR returns.

The other problem is tidying up the stack, and resetting the stack pointer. If that isn't done correctly, the return from the 'outer' ISR can not be simulated. The effect might be subtle with calculations going wrong, pointers damaged, loops wrong, etc. This will need assembler skills and good 'hardware debugging' skills to ensure it is tested and working.

If this isn't exactly correct stack memory might 'leak'.

Do you want me to proceed, i.e. does this sound feasible for you folks to write and debug? It is still quite involved, and I have limited bandwidth.

I would recommend getting a copy of The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors by Joseph Yiu ASAP if you don't already have it. It explains some of this stuff.

Answer 2

From the comments:

you look like your are stuck in an USB ISR waiting for another isr to compelte and on aborting you want to leave that USB ISR too. To do that, put a kind of "spin lock" in your USB ISR that also as a flag to notify from special events such as cancellation. With that flag you may simply issue a return or a goto to the end of your ISR to ignore next step (sending data back to usb). The flag is a nice thing, because if global enough, your "ordinary code" state machine will also be aware of the "result" of your USB ISR, namely a successful transfer or a cancellation/failure.