Strange current consumption events during sleep using iBeacon example

[jeremyherbert]

Hi,

I am compiling the iBeacon example from Zephyr (nrf-sdk 1.9.0), with only one modification to increase the advertising interval to 5000-6000ms. I have a custom nrf52811 board that has no semiconductors other than the nrf52811, and I am measuring the power using the PPK2. The floor current (at 3.3V) is 2-3uA as expected, and I get a spike up to ~15mA every 5 seconds which is also expected. However, there are strange multi-second events where the device is drawing many hundreds of uA, and I can't work out what they are from. I have attached a screenshot of the PPK2 output:

I have disconnected the programmer by unplugging it.

Could you please help me understand what these events are? I have attached my code.

nrf52811_test_beacon.zip

Thanks,

Jeremy

[Susheel Nuguru]

I haven't looked into your code yet but it looks like the spikes are in regular interval. Have you tested this on the DK? If not can you test it?

Also can you briefly explain which example you took as example and what changes you did?

[jeremyherbert]

Hi Susheel, 

yes, the sample was “ibeacon” and I only changed a single line which increases the advertising interval. I did tinker with some settings in the prj.conf around disabling the console and logging, but they didn’t make a difference.

I haven’t had a chance to try to reproduce on the DK, but also I am not sure if it is equivalent because it has an nrf52840, not the 52811.

[jeremyherbert]

I have just tried changing the advertising interval to 1 second, and the spikes still persist but they are much shorter than before (note that the x axis is now 10s instead of 1 minute):

[jeremyherbert]

If I build for the nrf52840dk_nrf52811 the same events still appear (the floor current is different though because I haven't optimised any GPIO levels or anything like that). I only changed the config to CONFIG_BOARD_ENABLE_DCDC=n so that the switching noise would go away.

5s interval:

1s interval:

[jeremyherbert]

Some more testing reveals that if I remove

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

and add

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=y

then the events go away on the nrf52840dk_nrf52811. So it seems like this is probably the RC oscillator calibration loop, except it is taking way too long to calibrate or not returning to sleep correctly after calibration. I think this is a bug in the calibration loop code, because if I use the online power estimator: https://devzone.nordicsemi.com/power/w/opp/2/online-power-profiler-for-bluetooth-le the LF clock calibration current should only be 1uA, not the 50uA I measured on my custom board:

[Susheel Nuguru]

jeremyherbert said:

then the events go away on the nrf52840dk_nrf52811. So it seems like this is probably the RC oscillator calibration loop, except it is taking way too long to calibrate or not returning to sleep correctly after calibration

It seems like the calibration of the RC is taking much longer than expected. We have seen this on devices that have a wrong PPM setting given to the calibrating module, But if you already have an XTAL on your device, why use RC?

[jeremyherbert]

In this case, I am using a device to test if I can remove the 32k XTAL and what the consequences would be. But this is not the consequence I expected... It seems that the RC oscillator is completely unusable?

[Susheel Nuguru]

RC 32k is usable but it is less accurate and needs more power to calibrate it constantly from hfclk crystal for the BLE protocol to work. The calibration time varies and can be power intensive over time. There are lots of discussion in this forum regarding using Rc 32k instead of XTAL

[jeremyherbert]

Hi Susheel,

Yes, I understand that it works in terms of providing a clock source, but the problem is that it draws more than 100x more current than the power profiler states it should, even on the nrf52840dk which is supposed to be a reference design. Could you help me understand why that is?

[Susheel Nuguru]

Sorry for the late reply Jeremy. Was away for few days.

There was a bug in the RC calibration in Zephyr in SDK version 1.9.0 which is fixed in SDK version 2.0.0.

We have also backported this fix to SDK 1.9.2. You need to use our softdevice controller for this and not Zephyr Controller.