Electronic – ARM cancel execution of pre-empted interrupts

armcortex-minterrupts

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.

Best Answer

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.

Related Solutions

Electronic – dsPIC33, SPI slave, and Timer1 interrupts. What happens

Normally you would set up the SPI peripheral once, then leave it on. The extra handshaking you are doing is preventing you from using the hardware to its full capability. Also doing a busy wait for the master to assert slave select is a bad idea if you ever want the processor to do something else.

Since you are transferring 16 bits of less per message, I would just let the hardware take care of it. Then you can monitor the SPI interrupt flag to determine when new data has been received from the master. If you need to slow down the master for flow control reasons, I would do that outside of the SPI message. I suspect the interrupt is adding latency to your home grown handshaking scheme, and something somewhere isn't quite right and can't tolerate that latency. That's assuming of course that the interrupt doesn't try to touch the SPI hardware or any of its I/O lines.

Electronic – Implementing an I2C buffer in C

I have no experience with PIC, but the problem seems generic enough. I would create a simple array with two independent pointers into the array: one read pointer and one write pointer. Whenever you receive a byte, you increment the write pointer and write at the new position; in your main loop you could then check if the read pointer and the write pointer are the same. If not, you simply read and process from the buffer and increase the read pointer for every byte until they are.

You could then either reset the pointers to the beginning of the array, or let them "flow over" to the beginning making essentially a circular buffer. This is easiest if the size of the array is a factor of 2 as you can then simply bitmask both pointers after their increments.

Some example (pseudo)code:

volatile unsigned int readPointer= 0;
volatile unsigned int writePointer=0;
volatile char theBuffer[32];
...
//in your ISR
writePointer = (writePointer+1) & 0x1F;
theBuffer[writePointer] = ReadI2C(); // assuming this is the easiest way to do it
                                     // I would probably just read the register directly
...
//in main
while (readPointer != writePointer) {
  readPointer = (readPointer+1) & 0x1F;
  nextByte = theBuffer[readPointer];
  // do whatever necessary with nextByte
}

Best Answer

Related Solutions

Electronic – dsPIC33, SPI slave, and Timer1 interrupts. What happens

Electronic – Implementing an I2C buffer in C

Related Topic