nRF5340 high sleep current with short-duration sleep

[Rory Morrison]

I'm looking into the power consumption of our code, and have reached the point where it looks like our application isn't going into sleep mode properly, and is using several hundred microamps more power than it should be.

We want to sample from the SAADC every millisecond, but in testing our board, I've been running some sample code instead. The most basic example is just a while loop that sleeps for 1 ms.

In this case, doing nothing but sleeping in a loop, our board is drawing 671 uA. If I increase the sleep duration to 5 ms then it's drawing 200 uA. If it sleeps for 1000 ms it's drawing something like 23 uA.

I guess some current overhead is expected when waking more frequently, but profiling the current using an otii it looks like the 1ms sleep code doesn't ever drop below about 650 uA. Whereas for longer sleep durations I can see the current drop much lower.

So, my question is - how long does it take the nRF5340 to go into sleep mode? If it's > 1 ms then that would explain what I'm seeing - the chip never gets to sleep as it wakes up before it can turn off the HF clock. If so, is there any way to make it enter sleep faster?

Alternatively, I guess it could be the otii - it's sampling at 4 kHz, so maybe that's just not enough to catch the drop in power in sleep mode.

[Karl Ylvisaker]

Hello,

Could you show some of the code that ran when you did these measurements?

The most basic example is just a while loop that sleeps for 1 ms.

I suspect that this means that you are doing direct calls to the manual call to sample, is this correct? This will require that the CPU is involved with every sample taken, which will increase your power consumption significantely.
To achieve the lowest power consumption when doing periodic SAADC readings we recommend that you connect the SAADC sample TASK to a CC event of a TIMER (or other periodic event generator), so that you avoid the CPU waking up to perform every sampling. If you do not immediately need to process every sample you can store them in a larger buffer, so that the CPU can wake to process them less often.
Please try this, and let me know if you see a sufficient reduction in your average power consumption.

Best regards,
Karl

[Rory Morrison]

I mean that literally just sleeping in a while loop draws hundreds of uA. No sampling, no interrupts, nothing.

void main(void)

{

    while (1) {

        k_msleep(1);

    }

}

Whereas sleeping for 1000 instead of 1 there draws ~23 uA

[Karl Ylvisaker]

Could you show me the entire code for your minimal project that you used to perform the measurements?

Best regards,
Karl

[Rory Morrison]

Okay, this is the code I'm profiling - I've removed everything that isn't just sitting in a while loop sleeping, and checked it's still behaving the same way. The 1 ms sleep version doesn't seem to drop below about 650 uA at any point, although I can see the current going up and down as the CPU goes in and out of sleep.

What I think is happening is that the HF oscillator doesn't have time to turn off if the sleep duration is only 1 ms, so we draw 650 or so uA. Whereas with a longer sleep duration it turns off in between and we can get a much lower current.

The reason I'm looking at this is that in our actual code we're using a GPIOTE interrupt to trigger sampling via PPI as you recommended above, and this is resulting in the same sort of behaviour, with, I think, the HF clock on permanently.

So I'm trying to work out whether a) this is correct, and the HF clock is staying on, b) If it is, is it possible to turn it off quicker and so save current, or c) if it isn't, is it possible to run the SAADC without turning the HF clock on at all.

minimal_current_profiling.zip

[Karl Ylvisaker]

Thank you for providing the minimal project, I'll do some testing here on my end and get back to you by the end of the week.

Rory Morrison said:

The reason I'm looking at this is that in our actual code we're using a GPIOTE interrupt to trigger sampling via PPI as you recommended above, and this is resulting in the same sort of behaviour, with, I think, the HF clock on permanently.

Ah, yes, the PPI will require the HF clock, but the draw of the HF clock is much lower than that of the CPU. CPU triggered sampling is only really more energy efficient if you sample very seldomly, or non-periodically.

Rory Morrison said:

a) this is correct, and the HF clock is staying on, b) If it is, is it possible to turn it off quicker and so save current, or c) if it isn't, is it possible to run the SAADC without turning the HF clock on at all.

It is correct that the HF clock will need to be enabled for the PPI to function, but it is also possible to run the SAADC from CPU triggered sampling, without PPI as well, but this usually comes with a higher power consumption for periodic / high frequency sampling. However, if you were to only sample once every second you could instead consider using the CPU to trigger this, rather than the PPI.

Best regards,
Karl