This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

interrupt enable and maskable interrupts

Other Parts Discussed in Thread: MSP430F5510

Hi.

I'm using a MSP430F5510. I have a doubt and I'd like a confirmation.

Consider that I'm using 2 different modules, let's say module A and module B.

Consider that the GIE is enable as well as the IE flag of module A and B.

If the IFG of module A  and module B get set at the same time, the interrupt with the higher priority is executed first.

Let's say that the module A's interrupt has the highest priority. Therefore module A ISR is executed.

Now consider that inside the module A ISR, module B IE flag is cleared.

After module A ISR end is module B ISR executed? I don't think so but i'd like a confirmation.

In other word, if i want to disable module B interrupt and the IFG flag is already set, is it enough to clear the IE flag or do i need also to clear the IFG flag?

In other word are interrupt IRQs latched?


Regards,

Carloalberto Torghele

 

  • Hi,

    well, the interrupt flags (IFGs) and the interrupt enable bits (IEs) are handled independently on MSP430. This means, the IFGs are set even in the case the interrupts are not enabled (IE=0). The interrupt enable bits are only used to allow interrupt generation (jump into ISR).

    In case an IFG is set while another ISR is executed and you clear this IFG bit during execution of ISR the other interrupt will not be handled.

    Regards.

  • Carloalberto Torghele said:
    If the IFG of module A  and module B get set at the same time, the interrupt with the higher priority is executed first.

    Right. Or if you clear GIE, both IFGs get set on any time durign GIE clear, and you then set GIE. Then too the one with the higher priority is executed first. If, however, the ISR for the lower priority intrrupt has been already called, teh higher priority interrupt won't interrupt it. During ISR execution, GIE is automatically cleared and no other interrupts occur. This is vital on interrupts with mutiple non-self-clearing IFGs (else you'd get an endless loop untiul the stack overflows). And a reason why oen shouldn't do anything time-consuming inside an ISR.
    However, it is possible (once you cleared the interrupt-causing IFG bit) to set GIE inside an ISR so any (even lower priority!) interrupt can be handled while the ISR is still doing its thing. But this includes that the same itnerrupt is called whiel it hasn't been finished handling the last call. It's a dangerous thing and shoul dbe used with extreme caution.

    Carloalberto Torghele said:
    is it enough to clear the IE flag or do i need also to clear the IFG flag?

    No. The interrupt request is an AND of IFG and IE and routed through a priority encoder (for multiple IFG/IE pairs on the same vector, they are ORed before being passed to the encoder). So as soon as one of the two, IE or IFG, is clear, the encoder will output the next lower interrupt as the next to be handled. Or none at all. However, an interrupt may happen (and be accepted and handled) exactly on or one MCU tick after the operation that disables the interrupt. This is caused by the pipelining structure of the processor. So between clearing GIE and entering an atomic instruction, there must be an additional NOP.
    For a similar reason there must be a NOP between an isntruction that enters LPM and a breakpoint that shall be triggered after return from LPM.

    Carloalberto Torghele said:
    In other word are interrupt IRQs latched?

    No. The IFG bits are latched. So the cause for a (possible, if enabled) interrupt is latched. but not whether an interrupt is enabled. This is a just-in-time test.

**Attention** This is a public forum