MSP430 post RETI behaviour

Hi folks,

does anyone know whether the MSP430 (F1611 being the one I
read about) will execute the opcode it returns to via its RETI
whether the interrupt mask is recoved from stack on or off?
 The 54xx DSPs do execute it (this made tracing an easy ride,
no hardware/cycle counting to do an NMI etc). But other CPUs
(those from Motorola, 68xx) do immediately take the next IRQ
without executing the code returning to...
 OTOH, the 430 does execute one opcode after the instruction
enabling the interrupts in its SR, so there is a hint of some
latency there, I may be lucky after all and not have to do NMIs... :-)

 Perhaps someone has been through that.

Thanks,

Dimiter

Didi kirjoitti:
 > Hi folks,
 >
 > does anyone know whether the MSP430 (F1611 being the one I
 > read about) will execute the opcode it returns to via its RETI
 > whether the interrupt mask is recoved from stack on or off?
 >  The 54xx DSPs do execute it (this made tracing an easy ride,
 > no hardware/cycle counting to do an NMI etc). But other CPUs
 > (those from Motorola, 68xx) do immediately take the next IRQ
 > without executing the code returning to...
 >  OTOH, the 430 does execute one opcode after the instruction
 > enabling the interrupts in its SR, so there is a hint of some
 > latency there, I may be lucky after all and not have to do NMIs... :-)
 >
 >  Perhaps someone has been through that.
 >
 > Thanks,
 >
 > Dimiter
 >

Hi Dimiter,

I am not sure what you ask but I try to answer. :-)

My understanding is that the mask is not in a sense recovered. And like in 
common market architectures, the highest interrupt source is serviced first and 
if you don't clear it, it is serviced immediatelly again. I haven't noticed that 
the programm could actually procee step by step after RETI in such situation but 
rather it stays stuck if you overlook it. Other kind of behavior would imply 
that at least a line is carried out before servicing the interrupt.

You can check it out yourself by not clearing a port interrupt (those being 
multiple source and not automaticly cleared), and put a LED light or similar 
instruction to the next op code line that follows a LPM3 or LPM4 in main loop.

Cheers,
Matti Ruusunen

Matti,

> ... I haven't noticed that
> the programm could actually procee step by step after RETI in such situation but
> rather it stays stuck if you overlook it. Other kind of behavior would imply
> that at least a line is carried out before servicing the interrupt.

Thanks, that's exactly what I wanted to know. So the 430 behaves like
most
other CPUs, not like the 54xx DSP (which executes one opcode after
returning
from IRQ with the mask off if IRQ is pending).

> You can check it out yourself by not clearing a port interrupt ...

Well yes, but I don't have the board with the 430 here yet. I already
designed for the case I am facing, though - one timer output is
connected
to the NMI input so tracing will work at the cost of a timer
reinitialization
every time one uses a single step trace, which is OK for me.

Thanks for the input,

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


On Sep 3, 10:27 pm, Matti Ruusunen
<matti.r3mov3this.ruusu...@gmail.com> wrote:
> Didi kirjoitti:
>  > Hi folks,
>  >
>  > does anyone know whether the MSP430 (F1611 being the one I
>  > read about) will execute the opcode it returns to via its RETI
>  > whether the interrupt mask is recoved from stack on or off?
>  >  The 54xx DSPs do execute it (this made tracing an easy ride,
>  > no hardware/cycle counting to do an NMI etc). But other CPUs
>  > (those from Motorola, 68xx) do immediately take the next IRQ
>  > without executing the code returning to...
>  >  OTOH, the 430 does execute one opcode after the instruction
>  > enabling the interrupts in its SR, so there is a hint of some
>  > latency there, I may be lucky after all and not have to do NMIs... :-)
>  >
>  >  Perhaps someone has been through that.
>  >
>  > Thanks,
>  >
>  > Dimiter
>  >
>
> Hi Dimiter,
>
> I am not sure what you ask but I try to answer. :-)
>
> My understanding is that the mask is not in a sense recovered. And like in
> common market architectures, the highest interrupt source is serviced first and
> if you don't clear it, it is serviced immediatelly again. I haven't noticed that
> the programm could actually procee step by step after RETI in such situation but
> rather it stays stuck if you overlook it. Other kind of behavior would imply
> that at least a line is carried out before servicing the interrupt.
>
> You can check it out yourself by not clearing a port interrupt (those being
> multiple source and not automaticly cleared), and put a LED light or similar
> instruction to the next op code line that follows a LPM3 or LPM4 in main loop.
>
> Cheers,
> Matti Ruusunen

Hi Dimiter,



Didi kirjoitti:
> Matti,
> 
>> ... I haven't noticed that
>> the programm could actually procee step by step after RETI in such situation but
>> rather it stays stuck if you overlook it. Other kind of behavior would imply
>> that at least a line is carried out before servicing the interrupt.
> 
> Thanks, that's exactly what I wanted to know. So the 430 behaves like
> most
> other CPUs, not like the 54xx DSP (which executes one opcode after
> returning
> from IRQ with the mask off if IRQ is pending).


Thing is that the people who designed MSP430, did not look at the 54xx or do 
things TI DSP way anyways. :-)

Addition to this, there was few years ago a common "agreement" that if you want 
to protect an instruction by DINT (global interrupt mask) you should place it 
one instruction ahead of the protected op code, or similar to Motorola-way, 
place a NOP instruction after DINT.

I can actually check it and post it here if my next project is with MSP430 and i 
was wrong. I work with the processor family in infrequent intervals.

Cheers,
Matti Ruusunen