AnsweredAssumed Answered

Unexpected Reset Status

Question asked by Charles Lehman on Jul 2, 2014
Latest reply on Jul 3, 2014 by Mark Butcher

I've been trying to get my code to tell the difference between a software reset and a watchdog timeout so that it can take some extra failsafe measures to avoid getting stuck in a reset loop. When I perform a software reset, it is through SCB_AIRCR, like this:

 

SCB_AIRCR = SCB_AIRCR | SCB_AIRCR_VECTKEY(0x05fa) | SCB_AIRCR_SYSRESETREQ_MASK;

 

After reset, I inspect the RCM_SRSx registers to determine what caused the reset. The problem is that whether it is from a watchdog timeout or a software reset, the following test always evaluates to true, even if I comment out all of the code that sets up the watchdog in the first place:

 

if (RCM_SRS0 & RCM_SRS0_WDOG_MASK) {

    /* fail-safe code */

}

 

It always handles power-on reset correctly, but software reset (which is performed occasionally as part of its normal operation) is always detected as a watchdog timeout. I tried making the check more robust by specifically excluding software and power-related resets, but it did not change anything:

 

if (((RCM_SRS0 & RCM_SRS0_WDOG_MASK) || (RCM_SRS1 & RCM_SRS1_LOCKUP_MASK)) && !(RCM_SRS0 & RCM_SRS0_POR_MASK) && !(RCM_SRS1 & RCM_SRS1_SW_MASK)) {

    /* fail-safe code, still incorrectly gets executed on software reset */

}

 

I can't figure out why the WDOG bit is getting set here, even when I keep the application from configuring the watchdog at all. When I use the debugger, it detects the software reset correctly, so I can't inspect the state of the registers when the error happens.

Outcomes