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?

[bjorn-spockeli]

HI Charles, 

I think this could be related to Errata  [136] System: Bits in RESETREAS are set when they should not be. 

Best regards

Bjørn

[charles]

Thanks for the quick response, Bjørn.

The errata you linked only mentions RESETPIN. In our case, we're not seeing RESETPIN, just LOCKUP | DOG. Would you mind being a little more explicit and confirm or clarify:

1. Is seeing LOCKUP | DOG also an errata? If not, is there a scenario where both could occur simultaneously? If there is, could you walk us through it please?

2. If we can't trust LOCKUP | DOG, which individual signal should we assume triggered the reset?

These signals are very important for failure analysis, so knowing which one (or both) are correct is critical.

Best,

Charles

[charles]

Heya Bjørn, I've confirmed that we do immediately read and clear RESETREAS.

We're trying to understand a scenario where LOCKUP and DOG could both be set. Our understanding is that entering core lockup immediately resets the part unless the debug interface is enabled. The units exhibiting LOCKUP | DOG are enclosed and in use in the field, with no debugging hardware attached to the SWD pins.

If we're wrong here, and the devices somehow have their debug interfaces enabled, then the datasheet specifies that the CPU will simply halt during a core lockup.

Could you help us understand these questions please?

1. nRF52832 v1.0 16.3 says 

"As long as the debugger is requesting power via CxxxPWRUPREQ, the device will be in debug interface mode. If the debugger is not requesting power via CxxxPWRUPREQ, the device will be in normal mode."

Is it possible to stand in core lockup with no debugging hardware attached?

2. If the unit is somehow standing in core lockup without a debugger attached, and the watchdog expires, would RESETREAS at startup be LOCKUP | DOG?

[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