Jump out from an interrupt got problem

[martinzhang]

Hi,

I'm using KM34 and prepared a jump function which can jump to any code by changing the SP and PC pointer. I have tested this function and it works OK in a normal status.

But when I put this jump function in to a timer ISR, the function can jump to the right position but all the interrupt cannot work.

Do I miss something when the function jumps out from an ISR?

BR,

Martin

[myke_predko]

@martinzhang ,

I think you have to explain what you are doing in a bit more detail.  When I read the responses from @bobpaddock , @jingpan  & @mjbcswitzerland they're all giving correct answers to different scenarios, the problem is it's not clear which one is correct.  

From what you've written, it sounds like to me that you've changed the Stack Pointer ("SP") and, unless you restore it before you attempt to return to the ISR, you're Program Counter ("PC") is going to be loaded with ...something... and, from your perspective, the system is going to crash.  

Without seeing your code I'm going to say that, as a rule, it's very bad form altering the stack in any way anywhere in your code (this includes the Stack Pointer) - let the system code/RTOS set up and manage that for you.  Just create your interrupt handler using the standard C format and don't touch the Stack Pointer.  

Could you share your code so we can more accurately diagnose the issue and give you suggestions on how to resolve it?  

myke

[jingpan · Accepted solution]

Hi martin,

I think this is because even if you jump to a new address, the M0 core is still in handler mode. It will block other interrupt which has lower or equal priority. You must return from interrupt to end handler mode first.

Regards,

Jing 

[bobpaddock]

Porting code from a different processor that changes the return address on the stack?

Look at the ARM documentation for the Link Register (LR).

[mjbcswitzerland]

The return address of an interrupt routine will be stored on the stack so if the SP is changed in the interrupt routine its return address will be lost....therefore either don't change the SP or else copy the complete stack to the now location before returning.

Regards

Mark

[bobpaddock]

Some (much) older RTOS's work by changing the return address on the stack of the original IRQ, not the stack pointer.  Other RTOSs work by having a stack pointer for each task, needing a stack copy. Some systems will even combine these two methods.

Getting back to the first 'returning' method, the normal Return from IRQ instruction is issued (to clear internal flags) and the new section of code is now running by 'returning' to it, even tho it was never called.  A jump someplace won't work as it doesn't clear the flags.

It is up to the RTOS to clean up and deal with what was the ORIGINAL return address of the IRQ in its task manager.

Some systems/processors will not allow this as it is a common security exploit.
'Buffer Overflow' issues can be manipulated to cause the 'return' to malicious code.