The short answer is yes, the NonMaskable Interrupt (NMI) on ARM Cortex M processors is non-clearable by software. The NMI is designed to be triggered by hardware events that require immediate attention from the processor, even during critical operations. Unlike regular interrupts, NMIs cannot be disabled or masked at any time. Once asserted, the NMI will be taken by the processor immediately after the current instruction completes execution.
What is a NonMaskable Interrupt?
A non-maskable interrupt (NMI) is a hardware interrupt that cannot be ignored by the processor under any circumstances. It has the highest priority among all interrupts in the system. When the NMI signal goes high, the processor will stop what it is currently doing and immediately start executing the NMI interrupt service routine (ISR).
The key characteristics of an NMI include:
- It cannot be disabled or masked by software.
- Has highest priority over regular interrupts.
- Causes immediate interrupt of current program execution.
- Dedicated NMI vector and ISR for handling the interrupt.
- Used for critical events that require urgent processor attention.
This makes NMI suitable for hardware faults, system errors, power failures and other critical events that need quick response from the processor. If used properly, NMI can help improve system robustness and recoverability.
NMI on ARM Cortex-M Processors
The ARM Cortex-M series of processors have built-in support for NMI. The NMI has fixed Vector number -1 on Cortex-M. This vector is distinct from the regular interrupt vector table and points to a dedicated NMI handler function. The NMI signal can originate from a peripheral module or external interrupt source.
When the NMI signal goes HIGH, the processor will complete executing the current instruction and then start executing the NMI ISR immediately. The processor also automatically stacks information about current program state, so that it can return after NMI handling. All interrupts except Debug Monitor are disabled on NMI entry.
The NMI ISR routine defined at vector -1 should quickly handle the event that caused NMI and clear the source if needed. After the ISR executes return from exception, the processor resumes normal operation.
Why NMI is Non-Clearable in Cortex-M
A key aspect of NMI in Cortex-M processors is that it cannot be cleared or disabled by software. The main reasons for this are:
- Reliable response to critical events – The NMI handler must execute in a timely manner when triggered regardless of what code is currently running. Software bugs or crashes cannot be allowed to mask or block it.
- Hardware triggered – The NMI is generated by hardware modules monitoring specific error conditions. Software cannot override hardware events.
- Fixed priority – NMI has higher priority than all other interrupts. Software cannot lower its priority or mask it.
- Dedicated vector – Unique vector number (-1) also prevents regular software from redirecting or blocking the NMI ISR.
These architectural mechanisms ensure that critical hardware events can quickly notify the processor through NMI. Software running on Cortex-M, including application code and OS, does not have any control to disable, clear or delay NMI handling when asserted.
Typical Usage Scenarios for NMI
Here are some typical use cases where NMI is used to handle critical events in Cortex-M based systems:
- Memory protection faults – If MPU regions are violated, the memory protection unit can trigger NMI.
- Watchdog reset – If the watchdog timer expires due to software fault, it can assert NMI while resetting the system.
- Power failure – Voltage detectors can generate NMI on power loss to alert the system to store state and shutdown cleanly.
- Clock errors – Clock monitor modules can use NMI to signal loss of clocks or clock failures.
- Parity or ECC errors – Memory and bus parity/ECC logic may use NMI for unrecoverable errors.
In each of these cases, NMI provides a reliable way for the hardware to signal the processor even if the software crashes or becomes unresponsive. Quick NMI response can improve field reliability against software failures.
Design Considerations for NMI Handlers
There are some unique design considerations for NMI handler code due to its non-maskable nature:
- Keep NMI handler code short, simple and efficient – it blocks other interrupts.
- Avoid complex functions or operations – use separate tasks if needed.
- Clear the source of NMI quickly – else it will keep recurring.
- Use stacked context state to recover or shutdown cleanly.
- Minimize usage of global variables – may be corrupted.
- No floating point usage – as lazy stacking is disabled.
- Consider using compiler intrinsics or directives for efficient code.
With good design, NMI handlers can provide critical response without disrupting normal operation. Rigorous testing is needed to verify correct behavior for all NMI sources.
Masking NMI in Special Cases
While generally NMI is non-maskable in Cortex-M, there are some special techniques that may be used to override or mask NMI in certain scenarios:
- The PRIMASK register can be used mask all exceptions temporarily.
- Debug halt requests can override NMI when the debugger is attached.
- Critical sections or special NMI masking code may temporarily block NMI.
- The processor can be reset or held in reset to mask external NMI events.
These techniques are usually just temporary or only used in special circumstances like debugging. Proper design should avoid misuse of such mechanisms to inappropriately block NMI handling.
Conclusion
In summary, the NonMaskable Interrupt on ARM Cortex-M processors is designed to be non-clearable and non-maskable by software. This ensures reliable response to critical hardware events used for NMI. Software should be designed to quickly handle and clear NMI causes. With proper usage, NMI improves fault responses and recovery handling in Cortex-M based systems.
