Questions on SRR

Firmware
1

I have two current projects where I keep track of the System Reset Reason (SRR). As part of the normal setup() process, I print out the last SRR using the following lines of code:

int sysRR;
sysRR = System.resetReason();

I then use a switch() statement to print out the specific reason using the following info I found in the docs:

RESET_REASON_PIN_RESET: Reset button or reset pin
RESET_REASON_POWER_MANAGEMENT: Low-power management reset
RESET_REASON_POWER_DOWN: Power-down reset
RESET_REASON_POWER_BROWNOUT: Brownout reset
RESET_REASON_WATCHDOG: Hardware watchdog reset
RESET_REASON_UPDATE: Successful firmware update
RESET_REASON_UPDATE_TIMEOUT: Firmware update timeout
RESET_REASON_FACTORY_RESET: Factory reset requested
RESET_REASON_SAFE_MODE: Safe mode requested
RESET_REASON_DFU_MODE: DFU mode requested
RESET_REASON_PANIC: System panic
RESET_REASON_USER: User-requested reset
RESET_REASON_UNKNOWN: Unspecified reset reason
RESET_REASON_NONE: Information is not available

I also found this chart showing the mappings…is this still accurate or is there a more recent copy?

RESET_REASON_NONE = 0,
RESET_REASON_UNKNOWN = 10, // Unspecified reason
// Hardware
RESET_REASON_PIN_RESET = 20, // Reset from the NRST pin
RESET_REASON_POWER_MANAGEMENT = 30, // Low-power management reset
RESET_REASON_POWER_DOWN = 40, // Power-down reset
RESET_REASON_POWER_BROWNOUT = 50, // Brownout reset
RESET_REASON_WATCHDOG = 60, // Watchdog reset
// Software
RESET_REASON_UPDATE = 70, // Successful firmware update
RESET_REASON_UPDATE_ERROR = 80, // Generic update error
RESET_REASON_UPDATE_TIMEOUT = 90, // Update timeout
RESET_REASON_FACTORY_RESET = 100, // Factory reset requested
RESET_REASON_SAFE_MODE = 110, // Safe mode requested
RESET_REASON_DFU_MODE = 120, // DFU mode requested
RESET_REASON_PANIC = 130, // System panic (additional data may contain panic code)
RESET_REASON_USER = 140 // User-requested reset

This works for several common events like flashing new code, powering off the unit, etc. My question revolves around the WDT. Since I’ve upgraded to 0.7.0 on my Photons, the WDT has “fired” and reset the box. At least I’m assuming it was the WDT since there was nothing else obvious that could explain why all of a sudden the box reset. I use the following WDT line of code:

ApplicationWatchdog wd(60000, System.reset, 1536);

I was expecting to see an SRR related to the WDT, but when this has happened so far, I get the “usual” reason:

RESET_REASON_USER = 140 // User-requested reset

I tried reading other questions on this topic but I never saw what I considered to be a complete answer to the question. Any help would be appreciated.

1 Like
2

The ApplicationWatchdog doesn’t generate RESET_REASON_WATCHDOG as it’s the software watchdog, not the STM32 hardware watchdog. Since you call System.reset as the watchdog handler, it generates RESET_REASON_USER as System.reset was called by user firmware. It just happened to be called in response to the software application watchdog, but System.reset does not know that.

2 Likes
3

@rickkas7, thanks for the clarification.

Is that list of reason mappings I listed above still current for the Photon/Electron? I use these codes in other non-Particle applications so I have to use the numeric equivalents since I don’t have the option of including Particle code.

4

Those look like the current reasons. The official list is here in the firmware source:

2 Likes
5

Perfect…thanks.