MSP430G2231: Code execution after ISR

Hi Sunset,

To clarify, you are talking about if I'm inside of ISR A, and interrupt B flag from another module gets set, what happens when ISR A ends before ISR B begins? And to confirm, you are not trying to do nested interrupts (enabling GIE inside of ISR so that ISR execution gets interrupted by other ISRs - that is not recommended).

From how I am reading the user's guide, I would interpret it that no, there would not be any execution before the new ISR. The following is my interpretation of the user's guide, but I would like to confirm this with our designers to make sure I'm correctly interpreting the operation for this case (so here is my theory but I'll work to confirm):
1. During ISR A, interrupt B flag is set
2. ISR A user code completes
3. Seeing user's guide section 2.2.3.2 Return from Interrupt, at ISR A completion, first the SR pops from the stack and the settings like CPUOFF, GIE are in effect. This means if you were in LPM before, you return to LPM. And because GIE is enabled, you will now start the acceptance process for Interrupt B which is set. PC is popped.
4. Seeing user's guide section 2.2.3.1 Interrupt Acceptance, first any currently executing instruction is completed. In this case, it is the PC being popped from returning from interrupt A in step 3. Then the PC that was just popped is pushed back onto the stack, and the rest of Interrupt Acceptance continues per the user's guide.

As I mentioned, this is my interpretation of the user's guide - no execution before the new ISR. But I will work to get a final confirmation here.

Regards,
Katie

Hello Katie,

My interpretation would also as yours.
It would be great if you could get the confirmation of it.

I can confirm that also your assumption are correct, no nested interrupt are enabled.
What happen between ISR A and ISR B, if IF for ISR B got enable while in ISR A?

Thanks for the followup

SunSet

I'm pretty sure one instruction is executed between the ISRs. I haven't found chapter and verse, but there is a hint in e.g. SLAU144J Sec 3.4.6.20 (EINT instruction): 

NOTE: Enable interrupt
The instruction following the enable interrupt instruction (EINT) is always executed, even if
an interrupt service request is pending when the interrupts are enabled.

In practice, this can be observed. When my, um, friend accidentally forgets to clear the interrupt source in an ISR, the program as a whole can be observed to execute, just really(!) slowly.

Never mind. When I got home I put together a little demonstration, and it .. doesn't work the way I said. I must have imagined the other incidents. ("It ain't what you don't know, it's what you know that ain't so.")

EINT and DINT have a delay because of the execution pipeline of the CPU. But when starting and returning from an interrupt handler, the pipeline must be flushed anyway, so it's logical that it can behave differently.

It's possible that your friend was running a different CPU.