Periodic (~4s) current blip in Low Power mode NRF52832 SDK V12.3

[koniho]

On a system using an NRF52832 with S132 softdevice (without no external LFCLK XTAL), in low power mode via sd_app_evt_wait() - we see a nominal current of ~3uA with a periodic current blip of ~100 uA.

There are a few other peripherals on the board - but we believe the blip is due to the NRF52832.

This blip occurs every ~4s.

The only NRF peripheral that can wake the system are GPIOTE events in low-accuracy mode (there are 3).

According to the datasheet - the 4s blip could be due to calibration of the LFCLK. Is the LFCLK required by the softdevice during sd_app_evt_wait()? - or does the GPIOTE peripheral require LFCLK?

[Matt]

Same test result if you disable ALL the other peripherals?

[AmbystomaLabs]

If you read through the SD spec, it discusses the periodic calibration of the LF_INT. The calibration is required to meet the BLE spec of 250ppm with the internal RC based RTC. The period of the calibration interval is configurable in the RTC config struct.

The RTC is the main clock when the system is asleep and for BLE it needs to be +/-250ppm all the time, thus the requirement to cal it against the HF_EXT.

The normal cal interval is around 17msec every 4 sec. Your plot looks consistent with it.

Here is more info on it: devzone.nordicsemi.com/.../

[koniho]

If BLE is not required while the system is sleeping - can the LFCLK be disabled? or will having the SD present always require the LFCLK to be active?

[AmbystomaLabs]

I think the only way to avoid the cal is to do a system power off or maybe a sd disable. Doing a WFE as you are doing is just holding it up until the next event comes through. The scheduled rtc cal is one of those events. And the ble core still needs to have an accurate clock for beacons, wakeup to listen events, etc. basically whatever you have told the ble core to do.

Are you trying to do a deep sleep with wakeup on a button? Exactly how were you planning to wake up the processor?

[koniho]

Yes - the current behavior for the device should be just to wake up from button press via GIOTE event. We should be able to guarantee that when the device has gone to sleep that BLE core will be inactive.