Expected current consumption for external RTC clock source on NRF52832

[Luis]

Hello, 

We have a battery-powered product that currently uses the NRF52832. It is a very low power space-constrained application, so we always evaluate any potential current consumption increase a change might cause. We currently use an external 32768 crystal as the clock source e for the RTC. As the NRF does not keep any time during a reet event we are planning to use an external RTC chip. This chip can both provide a buffered 32768 clock or a 1Hz clock. 

Our first idea is to source the 32768 clock to source the internal RTC of the NRF clock using the following workaround. However, I could not find any information on the datasheet on how much is the current consumption using this configuration. Is there any estimate on that? We could use the internal Low Power Oscillator, however, 250ppm is too much as a time drift for us. 

A second option is to route the 1Hz clock to a standard pin and emulate a soft RTC using the low accuracy GPIOTE (due to the power consumption). However, we already have several others sources of interrupts using the GPIOTE and as the low accuracy has a single interrupt handler, is there any possibility of losing an interrupt event?

Thanks a lot

[hmolesworth]

Unofficially I would say the consumption using an external 32kHz crystal-derived input is no more than using a 32kHz crystal connected to the nRF52832, which is the answer you are seeking. I have done this. Be sure to specify the correct drive level, which is probably full rather than minimal.

I would also argue that the external RTC may be unnecessary, as I have shipped multiple medical products using only the 32kHz crystal connected to the nRF52832 for timing and calendar functions. Yes a reset can distort timing, but why would there be a reset? Timing is set after the reset event; this scenario fails though if you require battery replacement during the life of the product, unless some mechanism is available to set the time after battery replacement.

Further keep all timing information in non-zeroed memory so a reset (unexpected) only loses a few mSecs but doesn't significantly distort time information; I have done this also.

[Luis]

Thanks a lot for your reply. All this information was very useful. 

Sorry for the late reply. For some reason, I did not receive any notification from the devzone.

Do you have a working example of keeping the time after a reset? We considered using the GPREGRET and GPREGRET2 but I would only have 16 bits on that. 

Thanks a lot

[hmolesworth]

You can use the predefined section .non_init (SES) or .noinit (IAR); check the .map file to verify it is set in the linker settings:

SES:

// Place following data in section .noinit so it doesn't get wiped on a reset
  static volatile uint32_t mIamInitializedRTC     __attribute__((section(".non_init"))); // Valid data indication for this data
  // 32-bit unsigned RTC time: number of 125 millisecond ticks from some arbitrary date (1/1/2021)
  static volatile uint32_t mRTC_PacketSampleTimer __attribute__((section(".non_init")));
// End - Place following data in section .noinit so it doesn't get wiped on a reset

IAR:

// Place following data in section .noinit so it doesn't get wiped on a reset
#pragma default_variable_attributes = @ ".noinit"
  static volatile uint32_t mIamInitializedRTC; // Valid data indication for this data
  // 32-bit unsigned RTC time: number of 125 millisecond ticks from Jan 1st 2021
  static volatile uint32_t mRTC_PacketSampleTimer;
#pragma default_variable_attributes =
// End - Place following data in section .noinit so it doesn't get wiped on a reset

If the 32-bit value mIamInitializedRTC is invalid then time has been lost and treated as a first poweron; if valid then the stored time is ok to keep using. Set the mIamInitializedRTC value to some incredibly wierdd magic number when initialised.

[Luis]

Thanks a lot. 

I will take a look on that. This should answer my question so far.