msp430 interrupt mechanism-why fixed priority fails

Tugrul,

By nature, the MSP430 can wake up from an external event trigger in less than 6us and still execute around 94 more instructions (running at 1MHz) to meet the 100us time requirement.

ali tugrul anildi said:

1-enable/disable each individual interrupt at entry of every ISR(which requires coordinating all interrupt code).

Once the device wakes up from Low Power Mode, the MSP430 automatically disables the global interrupt hence you won't need to worry about switching off all the other interrupt enables unless you want to do nested interrupts. You can do nested interrupts with the MSP430 but with care that the stacks do not get overflown.

ali tugrul anildi said:

2-shorten every ISR to the minimum reaction time and leave the rest of processing to the main thread.

That's true and it is one of our recommendations is to leave the heavy lifting down at the main thread.

Regards,

William

The main difference between maskable interrupts (IRQ) and non-maskable interrupts (NMI) is - that they are maskable. This means that while one IRQ function (ISR, interrupt service routine) is running, all other IRQs are masked, not disturbing the job. Priorized interrupts mean only that if more than one IRQ is pending (because they happened at the same time or during a period while IRQs are masked), the one with the higher priority will be executed first. It does not mean that a higher-priority IRQ will interrupt a lower priority one. Only NMIs will interrupt IRQs when IRQs are masked. Despite the name, NMIs are masked to - but only while an NMI ISR is being executed. Since NMIs are not maskable by software, allowing an NMI of the same level while executing the NMI ISR, would immediately iterrupt the ISR by itself as it doesn't have time to remove the cause of the NMI. User NMIs, however, can interrupt system NMIs and vice versa, bu tnot alternating. (at least on the 54xx series which as two separate NMI levels)

You can enable IRQs (unmask them) during execution of an ISR by setting the GIE bit manually. But you must be careful. ANY pending interrupt, even if lower priority, will immediately interrupt the ongoing ISR. And if you didn't clear the source of the current IRQ, the ISR will be interrupted by the very same IRQ that called it originally, causing an endless loop and stack overflow.

If you need to react to an event on a tight schedule, you shouldn't put complicated and lengthy code (this includes any division math operation or usage of float variables or busy-waiting loops) into any other ISR. Do in an ISR only what must be done immediately and leave the rest to the main code. From the power usage aspect it makes no difference whether you do the job in an ISR or wake up the main code, let it do the job and send it back to sleep then.

The maximum latency time for an ISR ranges from 5 MCLK cycles (if CPU is already running) over 5 MCLK cycles +6µs (if CPU is in LPM) to 5 MCLK cycles + execution time of any other ISR that is just running.

There is a trick to route some (few) IRQs to NMIs which interrupt always: whenever an IRQ event can also set an external port pin (such as CCIFG events), or if your interrupt source comes form outside, you can re-route the outgoing signal to the RESET pin and configure the RESET pin as NMI interrupt source. This will cause an user NMI which will interrupt even ongoing IRQs. But be warned, you cannot reset the processor anymore by the reset line. (it will even resist the JTAG interface). You'll need a power cycle to reset the device then.
I'm sorry that TI hasn't assigned the NMI functionality to a different pin, but maybe this is required for the BSL entry cycle (where the reset line is toggled to indicate a BSL request).