nRF52832: RESETREAS = 10, DOG | LOCKUP?

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

bjorn-spockeli — Tue, 22 Jan 2019 14:30:02 GMT

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

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

charles — Mon, 21 Jan 2019 17:58:15 GMT

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!

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

bjorn-spockeli — Fri, 18 Jan 2019 15:27:19 GMT

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.

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

bjorn-spockeli — Thu, 17 Jan 2019 15:06:34 GMT

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.

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

charles — Thu, 17 Jan 2019 08:05:45 GMT

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!

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

charles — Thu, 17 Jan 2019 02:39:21 GMT

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?

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

bjorn-spockeli — Wed, 16 Jan 2019 14:48:33 GMT

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

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

charles — Wed, 16 Jan 2019 13:57:19 GMT

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

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

bjorn-spockeli — Wed, 16 Jan 2019 13:25:14 GMT

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

RE: nRF52832: RESETREAS = 10, DOG | LOCKUP?

charles — Tue, 15 Jan 2019 20:57:43 GMT

We're using http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.4.pdf as a reference, 18.9.3 RESETREAS