"floor" current of 2.9 mA with code migrated to SDK15 (from SDK12)

[ThierryC]

I have an existing Firmware (build on Crossworks) that has correct "floor" power consumption (< 10 uA during sd_app_evt_wait() on my setup).

I migrate my code to rune with SDK15 (mainly changed SoftDevice API) and after that, I have a constant current consumption of about 2.9 mA !

Note that after SYSTEMOFF, I can correctly be < 1 uA.

So apparently I missed something during my porting and it seems that a resource is constantly alive. But I cannot figure out what it is.

Any hint to debug such issues ? Any register to check and see which resources are activated ?

Any suggestion or link to similar issue is welcome to help me to progress on this issue.

[Kenneth]

In general you may check out:
https://devzone.nordicsemi.com/b/blog/posts/optimizing-power-on-nrf52-designs

You may also take a look at the nrf_pwr_mgmt_run() implementation from the nRF SDK.

[ThierryC]

Here's more hints after further investigation : 

1. If I put nrf_pwr_mgmt_run() call in a loop at the begin of my main (after SD and BLE stack init), I got correct power consumption (almost zero or few uA)
2. If I move this loop later on may main init sequence, I got ~3 mA power consumption
3. Experimentally, I found the limit for 0 to 3 mA consumption to put the loop, and this is just after ONE (not the first) line sending some debug log to SERIAL.
4. If I put a LOG line into the nrf_pwr_mgmt_run() LOOP, event at the beginning of the main, the log is LOGGING forever... but maybe this is intended.
5. So I conclude this is due to logging into SERIAL, but in RELEASE build, I have same issue (but later on the main init sequence, seems to be at random line).

Reading your link, is seems to be something like point 1. in Software section : race condition and pending interrupt. But how to figure out the root cause of that ? Could it be related to interrupts priorities ? Any hint for this subject ?

[Kenneth]

If it is related to logging, then you can see how the SDK have solved this by waiting for logging to finish before going to sleep:

if (NRF_LOG_PROCESS() == false)
{
    nrf_pwr_mgmt_run();
}

The UART is the usual suspect when it comes to elevate current consumption during sleep, however it may also be other peripherals that are keeping the system powered, so I am not sure if I have any good suggestion than to for instance try to test a bit more.