sleep current during BLE advertising

[bios-bob]

i'm measuring approximately 1.5uA (at 3V3) when sleeping between BLE advertising events, using a program based on one of your the standard examples....

as an experiment, i built a trivial simple program that retains only SRAM blocks 0-1, enables the LFXTAL, and starts the RTC....  when sleeping, this program consumes about 1.68uA....

so now i'm curious as to what is *NOT* power/enabled/retained while the BLE program is sleeping???  

[Vidar Berg]

Hello,

The softevice is not doing anything "hidden" to reduce power consumption in idle mode, and there are no peripherals that would increase the idle current by this little when active. The only configuration I can think of that could cause changes in current draw at this level is RAM retention. The current consumption is typically around 30 nA per 4k of retained RAM.

Are you measuring on the same chip in both cases, and at exactly the same temperature? Note that ambient temperature can have a significant impact on sleep current.

Best regards,

Vidar

[bios-bob]

system_on_idle_test_nrf52.zip

5775.beacon_advertiser.zip

the first project is a very small program that simply goes idle, after setting up a limited memory retention as well as enabling LFXTAL and RTC....  when idle, this program ~1.68uA....

the second project is a large program built around a heavily-modified BLE advertising example....  when run, it only consumes ~1.5uA when idle....

to simply things even more, i have *NOT* called any of the bt_* functions in the second program; the program simply "goes idle" for ever....

i have also dumped numerous registers and have yet to find anything that explains why program 2) consumes less power than program 1)....  indeed, program 2) actually retains *all* RAM blocks -- and still does better....  both programs enable LFXTAL; and presumably when program 2) is actually advertising, it uses the RTC for wakeup....

again, you can even *FULLY ENABLE* BLE advertising in program 2) -- and it still only consumes ~1.5uA when idle....

though i haven't verified this for both programs, presumably they execute the same SystemInit() function which applies the various errata....

same nrf52K board, using a PPK2 to measure current....

i'm at a loss to find an explanation for the lower current in program 2)....

[Vidar Berg]

I think I may have found the problem. When triggering the LFCLK start task it will initially start up the RC oscillator while waiting for the crystal oscillator to ramp up, and it seems like both clock sources get kept enabled if you immediately start the RTC before the crystal oscillator has started (based on current draw). Adding the while loop below reduced the current consumption by around 0.2 ua in my case. This also seems similar to the symptoms described for the errata here: https://docs.nordicsemi.com/bundle/errata_nRF52832_Rev3/page/ERR/nRF52832/Rev3/latest/anomaly_832_101.html#anomaly_832_101

[bios-bob]

hi vidar,

you nailed it!!!   in my quest to minimize program size, i often find many of these while loops unnecessary....  indeed, but program "worked" -- but clearly missed the mark from a power perspective....

for sure, this is similar to the errata you cited -- though arguably there is a workaround....

as a consequence of your insight, i have a very small (~2K) BLE advertising program written in EM•Script which shows ~15% energy savings versus the Zephyr BLE advertising program attached earlier....  (FWIW, this code also supports the nRF54 series as well....)

again, thanks for the EXCELLENT support....

bob.

[Vidar Berg]

Good to hear, thanks for the update! A 15% reduction in power usage is significant. Would be interesting to know what the main contributor to this difference is. There is not much CPU processing in an advertisement event.