Is GPREGRET preserved across toggle of nRESET?

[Clem Taylor]

I'm trying to use gpreg for state across toggles of nRESET. I thought it was working, but when I tested it on hardware without jtag connected it seemed that gpreg was getting reset as well.

Before I go down the path of trying something else, should GPREGRET survive an external reset?

My hardware doesn't have any physical buttons and is glued shut. I'm concerned that during testing firmware builds on production hardware that I might push a some broken application firmware. Without working application firmware, you can't enter dfu mode. The one thing we do have is a reset button (wired to nRESET), so I'm using a range of gpreg values as a 'reboot counter'. Each time the bootloader starts (and the gpreg is <10) I add 1 to the gpreg. If the gpreg is < 10 && > 5, I automatically enter DFU mode. On the app side each time the watchdog timer is updated (from the main loop) I decrement the gpreg. So if you reset the device 6 times in a row (waiting few seconds between resets) it will automatically enter DFU mode.

On a possible related topic, it seems like RESETREAS often doesn't indicate that the WDT triggered the reset. My WDT_IRQHandler either triggers a breakpoint or just spins for the reset to occur. Sometimes when I reset back into the bootloader, POWER_RESETREAS_DOG is set and othertimes it isn't.

[Susheel Nuguru]

If you go to Power chapter and see "Reset Behaviour" section You will find that GPREGRET (retained registers) is only preserved for CPU lockup+Soft reset+Wakeup from SystemOFF.

nReset is pin reset. So the register will be cleared. Why don't you just write to application registered flash area? they will stay there, use pstorage update to update the flash content. I know that it will be slow, but I think there is no better solution for you.

Are you clearing the register bits of the RESETREAS after you check them. The only known anamoly for POWER->RESETREAS on latest nRF51 kits is 41. POWER RESETREAS register may erroneously indicate LOCKUP.

[Clem Taylor]

It isn't clear from the docs if sram is cleared on 'pin reset'. I can't imagine you would spend all the extra gates on a global reset for the sram block (not to mention the current draw of clearing all those bits when coming out of reset). I moved my 'flag' to the last 4 bytes of SRAM and again it works fine in the gdb, but doesn't seem to without jtag. Maybe my 'pin reset' macro isn't the same as stomping on the pin.

I am already under extreme flash pressure as it is, can't waste another page on a 'just in case' feature and I generally avoid writing to the flash for longevity reasons.

The bootloader reads, but doesn't write to RESETREAS, the application side reads and clears RESETREAS. I was commenting out the WDT ack and just letting it reset and some of the time I was seeing the DOG bit set when I reset back into the bootloader and other times it was cleared (I think it looked like a fresh power on). I stuck a gpio write in the WDT_IRQHandler() and watched it on the scope and saw the pin being asserted and released across the watchdog reset. I will have to repeat the test and look more closely. I just need to log to the host that the watchdog timer went off or we threw an assert.

[Susheel Nuguru]

It would be nice if you come back with your test results. Seems like some hardware issue, but I think WDT is well tested peripheral and hope that it is some thing else related to software.