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

[bjorn-spockeli]

Hi Charles,

I'm not aware of any known Erratas with the LOCKUP and DOG bits in RESETREAS being set when they shouldnt be. 

Are you seeing this consistently or is occurring randomly? Are you reading the RESETREAS register immediately after entering main(), printing it/storing the value and then clearing the RESETREAS register?

Unless cleared, the RESETREAS register will be cumulative, so it could be that this is two resets in sequence, e.g. either the CPU_LOCK occurs first and then at a later point the watchdog fires, or vice versa. 

Bjørn

[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.