RST/NMI input as NMI function to save critical data before reset.

Loc Pham said:

all functions that erase/write to flash will have interrupt disabled

Yet you cannot disable NMI. That's why it is called Non Maskable Interrupt. So if the reset comes during write, the system will crash, as it reads 0x3fff as NMI vector.

You can, however, forcibly put your NMI function at 0x3ffe, if this is possible. Then the NMI vector matches the 'dummy' value from the flash controller during a write operation. However, your NMI function will execute after the current write operation (erase/byte write) of the normal code is finished and then do its own write and reset, while the main functions flash write hasn't finished.

Also, keep in mind that you cannot use attach to 6-wire JTAG or use SpyByWire if the reset pin is switched to NMI.

Hello Jens-Michael,

The address 0x3ffe is currently being reserved. However, this is the only NMI function that I care for during normal operation.  If I disable NMI during flash write, will there be any other case that can cause the MSP to crash? Basically, will it work if I protect the the flash erase/write sequence by:

1. Clear NMIIE bit in SFRIE1register.

2. Perform erase/write to flash operation.

3. Set NMIIE bit in SFRIE1register to re-enable the interrupt.  This should trigger NMI interrupt immediately after flash write if a LOW pulse has been generated during flash operation.

The system can tolerate missing an RESET, but can not be crashed. Would that be sufficient?

Thank you very much for your input.

Loc

From 'normal program flow', it should be sufficient, if you can tolerate the risk of missing a reset.

However, there's always a chance of an ESD event or ionization by ambient radiation that can crash the device. The problem here is, that if it happens while the RST pin is configured for NMI, then even the external reset won't revive the device. Then only a power cycle will.
If you have the watchdog active, there is an excellent (but not 100%, as the fluke may have affected the watchdog art too) chance that it will trigger a device reset (without data saving) after the specified time.

that's a great point. I can implement the watchdog to improve the system reliability, but have to think more about the risk that requires power reset in case of crash. Unfortunately, removing power to trigger a power cycle is not an option for us. 

To understand more about the risk, is there any state that MSP430543xa can get into (by ESD, EMI, radiation...) that prevents the MSP from responding to NMI interrupt?  Would MSP have experienced some kind of damage in this state?  In this case, RST/NMI is the only NMI enabled and being highest priority to other IRQs.  Not responding to this NMI seems equivalent to not responding to RST (when configured for RST function).  In another word, is there any state that device can crash, will not respond to reset signal, and need a power cycle to revive even if RTS/NMI is left default for RST function?

Thank you so much for your input.

Loc Pham said:

is there any state that MSP430543xa can get into (by ESD, EMI, radiation...) that prevents the MSP from responding to NMI interrupt?

Sure. As well as spikes on th e(external) clock, ESD, EMI or radiation can make the MSP core crash. Then it won't work as expected and most likely not responding to interrupt s8whether NMI or IRQ) or do anything at all.

Loc Pham said:

Not responding to this NMI seems equivalent to not responding to RST

No. RST is a physical signal. It resets the device, the hardware, everything. However, the routing of the RST pin to the internal reset logic can be altered, so the signal is routed to the NMI logic instead. This routing is done on logic gate level, the CPU core only initiates it by writing to a register (which is just a memory address for the CPU core).

Loc Pham said:

In another word, is there any state that device can crash, will not respond to reset signal, and need a power cycle to revive even if RTS/NMI is left default for RST function?

Yes. Almost. YOu can misprogram the device so it enters an eternal reset cycle and you cannot connect to it with JTAG. But this doe snot apply if the firmware is working. It only happens sometimes during development when a buggy firmware is uploaded and immediately causes a reset (e.g. access violation etc.). Then the FET has no time to attach to the device before it resets itself again. However, the device does respond to a reset. Just it won't help as the buggy firmware is still onit.

Another possible state is when the flash content is damaged by ionization, overvoltage or such. Sure, if the firmware is destroyed, a reset won't help.

Loc Pham said:

removing power to trigger a power cycle is not an option for us. 

But you can attach a transistor to VCC and shortcut VCC by a logic (e.g. a monoflop that starts when the reset signal comes and expires if the MSP doesn't answer in time. Sort of an externally started watchdog.). Put a small series resistor in ine to VCC, so you don't shortcut the power supply but only the VCC input of the MSP.

The watchdog will, if configured and handled properly, reset the device and therefore the CPU core, if it isn't triggered in time. So if the cpu crashes and doesn't respond to NMI anymore, the watchdog will reset it. The software can even detect whether it was a watchdog reset, since the WDTIFG bit is still set after the reset.

Loc Pham said:

is there any state that MSP430543xa can get into (by ESD, EMI, radiation...) that prevents the MSP from responding to NMI interrupt?

Sure. As well as spikes on th e(external) clock, ESD, EMI or radiation can make the MSP core crash. Then it won't work as expected and most likely not responding to interrupt s8whether NMI or IRQ) or do anything at all.

Loc Pham said:

Not responding to this NMI seems equivalent to not responding to RST

No. RST is a physical signal. It resets the device, the hardware, everything. However, the routing of the RST pin to the internal reset logic can be altered, so the signal is routed to the NMI logic instead. This routing is done on logic gate level, the CPU core only initiates it by writing to a register (which is just a memory address for the CPU core).

Loc Pham said:

In another word, is there any state that device can crash, will not respond to reset signal, and need a power cycle to revive even if RTS/NMI is left default for RST function?

Yes. Almost. YOu can misprogram the device so it enters an eternal reset cycle and you cannot connect to it with JTAG. But this doe snot apply if the firmware is working. It only happens sometimes during development when a buggy firmware is uploaded and immediately causes a reset (e.g. access violation etc.). Then the FET has no time to attach to the device before it resets itself again. However, the device does respond to a reset. Just it won't help as the buggy firmware is still onit.

Another possible state is when the flash content is damaged by ionization, overvoltage or such. Sure, if the firmware is destroyed, a reset won't help.

Loc Pham said:

removing power to trigger a power cycle is not an option for us. 

But you can attach a transistor to VCC and shortcut VCC by a logic (e.g. a monoflop that starts when the reset signal comes and expires if the MSP doesn't answer in time. Sort of an externally started watchdog.). Put a small series resistor in ine to VCC, so you don't shortcut the power supply but only the VCC input of the MSP.

The watchdog will, if configured and handled properly, reset the device and therefore the CPU core, if it isn't triggered in time. So if the cpu crashes and doesn't respond to NMI anymore, the watchdog will reset it. The software can even detect whether it was a watchdog reset, since the WDTIFG bit is still set after the reset.

Hello Jens,

Thank you so much for your detailed explanations. I'll have the watchdog implemented, and move forward.  I appreciate the suggestion for a reset via Vcc short and take that into consideration for next project as we can't do any mod to current board.

Kinds regards,

Loc