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.
-
A POR. In which case the contents of RAM can not be trusted. POR can be caused
by:-
-
Powering on the device, when RAM is indeterminate.
-
A Low signal on RST if set for reset mode. RAM may be indeterminate
-
A low power condition with PORON set. RAM cannot be trusted
-
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.
-
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.
-
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.
-
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.
-
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.