Retain 32 bits across a watchdog reset ?

RE: Retain 32 bits across a watchdog reset ?

AmbystomaLabs — Thu, 22 Jun 2017 01:07:01 GMT

Excellent! Glad to hear it's a good solution.

RE: Retain 32 bits across a watchdog reset ?

Hein — Wed, 21 Jun 2017 21:55:27 GMT

Update . . . storing to ram before a watchdog reset seems to work well. I've got some guard uint32_t variables around the value I care about, so at least in theory I should be able to detect ram corruption, but it seems the chances of ram corruption with a normal watchdog reset are pretty low. For a brownout or power on reset I clear the variables anyway, so not too concerned about that.

Our devices update their real time every time they make a BLE connection (usually daily) anyway, so not too worried about keeping great time, in practice 20ppm over a year would be a fantastic result.

Thanks for your input and advice AmbystomaLabs and Daniel Wang.

RE: Retain 32 bits across a watchdog reset ?

Daniel Wang — Wed, 21 Jun 2017 19:16:21 GMT

For "real time clock"/calender, check out the nrf5-calendar-example: github.com/.../nrf5-calendar-example

RE: Retain 32 bits across a watchdog reset ?

AmbystomaLabs — Wed, 21 Jun 2017 17:47:10 GMT

The RTC on most microcontrollers is really just a tick, app_timer kind of thing. And, for bluetooth it runs sleep/wake to keep the framing correct. At 20ppm it's not going to keep great time anyway. It might be for that reason that they refer to it as a real time counter and not real time clock.

There are a lot of good real time clock solutions out there in tiny packages and only draw nanoamps. Plus they have internal registers that will keep time for roughly forever. Interfaces are simple i2c, 1 wire or 2 wire serial. Most are around 1 to 2ppm. Or under 1 minute error annually. This might be a better solution if you have high performance time keeping requirements. Plus at nanoamps these can normally be run from soldered in rechargeable button cells so they even run with power off.

RE: Retain 32 bits across a watchdog reset ?

Hein — Wed, 21 Jun 2017 01:27:05 GMT

Also, because the RTC is 24bit with a 12bit prescaler, you cannot really use it to keep real time for years. At maximum values, it would overflow every 24 days or so if my quick math is correct. This means to do a low power timebase that runs for years, I had to use the PPI to clock a 32 bit counter every second, which then also turns on the HF clock briefly at every event, which causes a extra 100nA or so on average of extra power consumption in sleep mode. This problem could have been avoided by either being able to use the 32k clock for a 32bit timer or by making the RTC 32 bit.

RE: Retain 32 bits across a watchdog reset ?

Hein — Wed, 21 Jun 2017 01:21:26 GMT

Yeah, I should have added that we are ultra low power, our devices usually sleep @ less than 2uA to get the lifetime we require from a CR2032. No chance of writing to flash and even having to wake up the high frequency clock every second just to store the timer value make a real difference to our sleep current.

I have experimented with writing the timer to a .noinit global variable and it looks to be working well in practice. I would have liked to store the timer value to this variable in the watchdog event handler, but it seems I cannot initialize the 32 bit counter to the stored value at startup ? Still trying to think about a simple way around all these catches.

RE: Retain 32 bits across a watchdog reset ?

AmbystomaLabs — Wed, 21 Jun 2017 00:31:11 GMT

Well you could push your 32 bit register to flash between watchdog refresh cycles. Unless your watchdog time is unusually short this shouldn't use much power. Then on reboot you can look for the data and load if available. At worst you will be off by one watchdog cycle. The reality is you would always be off a little on a watchdog reset since the RTC won't be configured on reset.

As for the RTC timer, a second of 32768 fits nicely in 16 bits so even 24 bits is overkill let alone 32 bits. Don't know if they had a reason for it though.

According to the spec, ram does not reset under any circumstance. They warn that it could be corrupted depending on the reset reason (eg, brownout). So, you could just write the 32bit word to ram once a second and just make sure to not initialize the variable in C. Sounds silly, but it should work.

RE: Retain 32 bits across a watchdog reset ?

Hein — Tue, 20 Jun 2017 23:20:53 GMT

Also, why on earth would the GPREGRET registers not be 32 bit ?!?!?!