nRF5340 SAADC power consumption

[Rory Morrison]

I'm profiling the current consumption of our device, on an nRF5340 module, at SDK 2.1.0.

So far as I can tell, the ADC is using approximately 1000 uA. It's sampling via PPI, and is triggered from an external clock signal at 1 kH.

The current consumption figures for the SAADC here show typical current consumption based on different configuration options. It looks like ~1000 uA is on the high end of what is expected, and that setting LPOP=LowPower would save us a considerable amount of current.

However I can't find anything about LPOP or LowPower anywhere else, either in the SAADC documentation or in the SDK.

Any tips as to where This can be enabled? I've seen this for an old version of the SDK, but it seems to come down to setting saadc_config.low_power_mode = true; which isn't part of the config struct in the current SDK.

[Rory Morrison]

Those EVENTS_SLEEPENTER and EVENTS_SLEEPEXIT sound useful - I'll give that a try to confirm how long the CPU is asleep/awake.

Just to clarify, the current consumption above is in the sample button project with the code to initialise our external RTC copied in, and the interrupt changed to the RTC pin on our board. I also swapped the interrupt code to use nrfx_gpiote in the same way as our main project.

As far as I'm aware there shouldn't be any interrupt callback actually running, as nrfx_gpiote_in_event_enable(pin, false); will mean it doesn't actually call the handler.

Since all it does is initialise the RTC and enable the interrupt, there shouldn't be any other code running. I'm assuming that when the interrupt fires it wakes up the CPU, there's no ISR and no PPI/SAADC configured either, so it should just go straight back to sleep.

I opened this support request to try to get to the bottom of what might be going on with the CPU sleep without worrying about the SAADC, PPI, interrupts etc. and just looking at the current consumption if we sleep in a while loop. As I mentioned before, I was getting ~650 uA in the button sample project just sitting in a while loop sleeping for 1 ms at a time, but only 23 uA if I set the sleep time to 1000 ms.

I guess based on your reply, it might be taking ~250 us to go back to sleep from a GPIO interrupt, and ~150 us to go to sleep when just sat in a while loop. At least that would be consistent with the current figures. Is that longer than you would expect?

[Rory Morrison]

Hi Jørgen,

I've managed to get a pin toggle from the sleep enter/exit events. In my test code I can see a 40 uS pulse when the CPU is awake with an interval of 1 second. That corresponds to the 1000 ms sleep in a while loop that I have at the end of my test main function.

The rest of the time the CPU is off, so the ~1 mA current draw must be solely down to the GPIO interrupt.

Some of that I suspect is down to the nrfx gpiote config - I think I can save a few hundred uA by using the nrf_gpiote library, triggering off a high or low signal instead of an edge, and changing the latency.

It looks to me like, since it's not the CPU, something to do with the GPIO is keeping the HF oscillator on in between interrupts.

Rory

[Jørgen Holmefjord]

Hi Rory,

Would you be able to share your test sample with me? Then I could try it out on my board and see if I can figure out what is causing the higher current consumption.

Best regards,
Jørgen

[Rory Morrison]

Hi Jørgen

I'll put together the minimal version of the code today (mostly just removing all the extra stuff I've got commented out!).

Bear in mind that you'll need an external square wave source to generate the clock signal - without that present the current draw is fairly low, it's only when the interrupt is triggered at ~1000 Hz that we get 1 mA of current draw.

Thanks,

Rory

[Rory Morrison]

Okay, this is the project.minimal_interrupt.zip

I've left in the code to toggle a pin when the CPU wakes. The only other code in there is to enable the external interrupt, and then sleep in a while loop.

I just checked the current, and I'm still getting ~1000 uA when it's triggering from the external RTC, and ~83 uA when it's triggered from an unused pin.

I haven't checked the pin toggle, but the other day it was triggering once per second for about 80 us, which corresponds with the while loop waking up and sleeping again.