sleep current during BLE advertising

RE: sleep current during BLE advertising

Vidar Berg — Wed, 15 Apr 2026 07:30:44 GMT

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.

RE: sleep current during BLE advertising

bios-bob — Tue, 14 Apr 2026 13:50:17 GMT

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.

RE: sleep current during BLE advertising

Vidar Berg — Tue, 14 Apr 2026 13:23:43 GMT

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

RE: sleep current during BLE advertising

bios-bob — Tue, 14 Apr 2026 03:56:09 GMT

devzone.nordicsemi.com/.../system_5F00_on_5F00_idle_5F00_test_5F00_nrf52.zip

devzone.nordicsemi.com/.../5775.beacon_5F00_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)....

RE: sleep current during BLE advertising

bios-bob — Mon, 13 Apr 2026 13:18:08 GMT

same device, with measurements taken in quick succession.... i agree with your RAM retention theory.... is there any way to find out exactly how much RAM is retained by the stack???

RE: sleep current during BLE advertising

Vidar Berg — Mon, 13 Apr 2026 06:45:03 GMT

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