TI MSP430 Microcontroller Interrupts

State of RAM after reset

Keep in mind that most C compilers will automatically include code to erase RAM on PUC.

A PUC (Power Up Clear) is ALWAYS generated by a POR (Power On Reset), but a POR is not always generated by a PUC. Certain things that cause a PUC will not necessarily alter RAM. A PUC is generated by the following events, as outlined in the Users Guide.

1. A POR. In which case the contents of RAM can not be trusted. POR can be caused by:-
   1. Powering on the device, when RAM is indeterminate.
   2. A Low signal on RST if set for reset mode. RAM may be indeterminate
   3. A low power condition with PORON set. RAM cannot be trusted
   4. Unless specifically handled by user ISRs the NMI_ISR will usually ultimately result in the system hanging in an unknown state. If all the user does is effectively an RETI for the NMI then the same will usually occur eventually.
2. Watchdog timer expiry, if enabled. this will normally leave RAM unaltered. However, if the time expired due to a processor crash, there is no way of knowing what the processor did to the RAM before the watchdog reset.
3. Watchdog Timer security key violation rather than expiry. This is typically caused by a program bug or a processor crash. Do not trust RAM. Some people purposly write an invalid key to trigger an instant watchdog reset. If that is the only cause, the RAM is probably fine.
4. Flash memory security key violation. Again, RAM can not be trusted. The NMI handling routine could try and determine the cause of this, or, if possible log the last few bytes of Stack.
5. CPU instruction fetch from peripheral memory. Jumping to IO memory is abnormal. Again this only occurs if there is a serious bug in the system, or something has become corrupted, so don't trust RAM.