After a device reset occurs, the lowest level reset cause which occurred during reset processing is captured in hardware so that application software can interrogate the reason for the reset and take any appropriate action when starting the application. The lowest level reset cause is encoded into a 5-bit field in the reset cause register in SYSCTL. The contents of the reset cause register are always cleared upon a read, and return zero after being read if no reset has occurred after the read. The reset cause encodings are given in Table 2-9.

If two reset causes occur simultaneously, the lowest cause reset ID value is prioritized and reported. For example, if a WWDT0 violation (cause 0x12) occurs at the same time that a VDD < BOR- violation (cause 0x04) occurs, the reported reset cause is a BOR- violation (cause 0x04), as this is a lower level reset which clears additional aspects of the device state.

The reset cause encoding enables simple software handling during application startup. The reset cause value can be read by application software and tested to be within a certain value range to determine if the following occurred:

• RESETCAUSE==0x00: No reset since last read
• RESETCAUSE<0x04: The NRST/SWD disable state was reset and can need to be reconfigured
• RESETCAUSE<0x04: The SHUTDNSTOREx memory was reset and can need to be reconfigured
• RESETCAUSE<0x08: The regulated VCORE domain, including the SRAM, was power cycled
• RESETCAUSE<0x1C: The peripherals were reset and can need to be reconfigured

The following example shows how the reset cause can be tested to take specific actions when starting an application after a reset:

// Read reset cause into SRAM variable
uint8_t cause = RESETCAUSE;

// Handle device re-configuration based on reset cause level
if (cause!=0)
{
	if (cause<0x04)
	{
		// NRST/SWD disable state was lost
		// SHUTDNSTOREx memory state was lost
		// PMU/VCORE domain state was lost
		// RTC/LFXT/LFCLK state was lost
	}
	
	if (cause<0x1C)
	{
		// The peripherals were reset
	}
}