nRF52832: RESETREAS = 10, DOG | LOCKUP?

[charles]

We're reading RESETREAS at startup from our nRF52832 cpu, and getting the value 10. The docs show that this refers to DOG and LOCKUP bits both being set. We don't have the debug interface enabled, so core lockup should be resetting immediately. Similarly, the watchdog simply resets upon expiry.

Can anyone explain what it means to have a RESETREAS value of 10 at boot? What scenario would lead to this?

[charles]

Update: we've identified a potential path through the code where we do not read + clear the RESETREAS immediately, so we could be seeing the signals accumulate up. Still looking into it, though answers to the previous questions would still be appreciated if possible!

[bjorn-spockeli]

Hi Charles, 

Q1: According to the ARM Cortex-M4 Devices Generic User Guide 

The processor enters a lockup state if a fault occurs when executing the NMI or HardFault handlers. When the processor is in lockup state it does not execute any instructions. The processor remains in lockup state until either:
  • it is reset
  • an NMI occurs
  • it is halted by a debugger.

as the lockup it self will cause a the chip to reset and you do not have a debugger connected then I would have to say no, its not possible for the core to remain in a locked up state with no debug hardware connected. 

Q2: Do not think that this is possible as stated in Q2. Will confirm this internally.   

[bjorn-spockeli]

HI Charles, I just realized that a reset caused by a CPU lockup will not clear the Watchdog. So if the CPU lockup occurs and then the WDT will still be running after the reset and then timeout. 

[charles]

I see, so if there isn't any errata that applies here, two possible scenarios are:

1. We're in an infinite loop somewhere, WDG resets us, and we enter a core lockup before we check + clear RESETREAS.

2. We experience a core lockup, and when we reset, we enter an infinite loop before we check + clear RESETREAS.

In both scenarios, the end result is LOCKUP | DOG set in RESETREAS.

This is plausible; we save state in a section of RAM that we retain across resets; if that's getting corrupted we might see issues like this.

Anyway, it sounds like there aren't any errata that apply, and that if we see LOCKUP | DOG in RESETREAS, it's real and being correctly reported. 

If that's the case, then let's close this ticket. Thanks for your help!

[bjorn-spockeli]

Hi Charles, 

Yes, I think that these are the two plausible scenarios that will result in LOCKUP | DOG set in RESETREAS.. I cannot find any errata that describes RESETREAS registers erroneously indicating LOCKUP | DOG or LOCKUP or DOG individually 

Best regards

Bjørn