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]

Okay, I had the wrong idea a couple of days ago - in the sample button code, it sleeps for 1 ms in a while loop, and if I make that 1000 ms instead, the current consumption drops massively. I think that whole reply can be safely ignored!

I've now copied over our interrupt code, so I can test it in isolation from the rest of our code. If I initialise the interrupt using a spare unconnected pin, I get current consumption of ~90 uA, and this is with the sense set to NRF_GPIOTE_POLARITY_HITOLO, which I suspect means we're doing edge detection, which adds some extra current. So that's encouraging.

If I go back to using our external 1000 Hz RTC signal, I get just over 1 mA consumption. But I can set the prescaler on our external RTC to give different interrupt frequencies, and this is where things get weird...

The pink line is 1000 Hz interrupts, and just over 1 mA current. The blue line is 250 Hz interrupts, and about 220 uA. The purple line is 500 Hz and oscillates between ~90 uA and ~220 uA.

(The low power at the beginning is 2.5 seconds of sleep, the code to set up our external RTC over spi, and then 2.5 seconds of sleep again)

All I can think is that the timing of the MCU going to sleep somehow requires > 1 ms for it to kick in, and so at 1000 Hz interrupts, we never get there. Or rather, I guess the idle current still has the HF oscillator on for ~1 ms?

This is the config/init code I'm using - so the interrupt is disabled, and so button_pressed shouldn't be being executed. And I've done nothing to initialise the ADC or PPI.

    static const nrfx_gpiote_in_config_t pin_interrupt_config = {

        .sense = NRF_GPIOTE_POLARITY_HITOLO,

        .pull = NRF_GPIO_PIN_PULLUP,

        .is_watcher = false,

        .hi_accuracy = true,

        .skip_gpio_setup = false,

    };

    nrfx_gpiote_in_init(pin, &pin_interrupt_config, button_pressed);

    nrfx_gpiote_in_event_enable(pin, false);

[Jørgen Holmefjord]

Hi,

Have you checked how long the execution time of the interrupt is? You can use GPIO toggling in the interrupt handler to check that, or toggle a GPIO at the end of the handler and compare this to the GPIO input. It is also possible to use DPPI and GPIOTE to toggle a GPIO from the POWER->EVENTS_SLEEPENTER and EVENTS_SLEEPEXIT to see when the CPU is actually in sleep.

If for instance the interrupt takes 250us to complete, the ~1mA avereage current makes sense as it will make the Application CPU running about 25% of the time. This also makes sense for the 250Hz current. The 500Hz current does not make sense, but there could be some other error with this. Have you checked that the interrupt actually happens at 500Hz with this configuration? Is there anything in your application that corresponds with the rate that it toggles between high and low current consumption?

Best regards,
Jørgen

[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.

[Jørgen Holmefjord]

I tried your sample, but I'm not able to reproduce the behavior you are describing.

I see the same current consumption, regardless of which pin I pass to configureNrfxGpioInterrupt() (KHZ_CLOCK_PIN or UNUSED_INTERRUPT_PIN), the current draw is ~76 uA average without input (pin tied to GND), ~138 uA with 1 kHz input, ~101uA with 500 Hz input, and ~86 uA with 250 Hz input.

Have you tested this on multiple nRF5340 modules? Have you reproduced it on a nRF5340 DK?

[Rory Morrison]

Hi Jørgen,

That's encouraging, in a way. So far I haven't managed to get a sensible-looking current measurement out of the DK board at all. I'm trying to use a scope across a 10 ohm resistor as described in the infocenter documentation, but I get even higher curent consumption than I do when I measure our own boards.

It looks like something on the DK stays powered even when I've set it to only power the nRF53 - can you walk me through exactly how it needs to be powered and how to set the microswitches to measure just the nRF53?

Alternatively it might just be easier to use the nordic PPK - I'll see if we can order one.

Other than that I just want to double check what SDK you used? I've been using 2.1.0. That's the only thing I can think of apart from the hardware or my measuring setup that could be different.

Thanks,

Rory

EDIT - the scope I'm using is a RIGOL DS1054Z which doesn't have a differential input mode, so I'm relying on the math function to get the difference between two channels. It seems like I can either have low resolution on the two channels, meaning the measurement noise is larger than the <1 mV signal I'm trying to measure, or I can have higher resolution, and the current measurement pins being at ~3V mean they're both off the scale so I get no signal at all. We've ordered a PPK so hopefully I can get a measurement with that in a couple of days.

[Rory Morrison]

Ok, I now have a PPK II which makes measuring current a lot easier.

I can confirm that on our hardware I still see ~1 mA of current with the RTC at 1000 Hz. But at 500 Hz I get about 90 uA with occasional large spikes... 

Those spikes, closeup, look like this

 or sometimes this 

So it looks like *something* turns on with the big spike, then triggers one or more times before turning off again.

The 1000 Hz RTC version looks like this

Which seems to just be the 3 mA spikes, at 2 kHz.

At this point it looks like it must be our hardware doing this, except I can get sort of similar behaviour on my dev kit, by sleeping in a loop for a few milliseconds. Sleeping 1 ms in a loop looks like this

Those small sawtooth peaks are at about 1000 Hz, so correspond to the CPU waking up and immediately sleeping. Those bigger 3 mA spikes look similar to what I get on our board though, seemingly at random intervals...

I don't have a signal generator to hand, so will try the dev kit on Monday to see if I can reproduce the 1000 Hz behaviour on the dev kit.

In the mean time - any idea what those 3 mA spikes might be? Particularly on the Dev kit current profile?

[Rory Morrison]

I've now got the dev kit attached to a function generator, and I'm getting similar current consumption to yours, although not exactly the same. But it seems to be in the region of 100 to 150 uA depending on the frequency.

I've discovered that the RTC chip we use on our own board is powered from the VCC output of the nRF chip at 1.8 V. To do this we're using the chip in high voltage mode. It also seems like it defaults to using the DCDC converters for voltage regulation instead of the LDO, which is not what it says here.

But if I add 

CONFIG_BOARD_ENABLE_DCDC_APP=n

CONFIG_BOARD_ENABLE_DCDC_NET=n

CONFIG_BOARD_ENABLE_DCDC_HV=n

to the prj.conf file, I get very different looking current consumption - and about 445uA on the dev board and 485 uA on our own board.

Any idea why it's defaulting to using the DCDC? Or why (apparently) using the VCC output to power the RTC that triggers the interrupt might cause problems when the DCDC converters are on? 

I did also notice that the config for the interrupt pin included a pullup - I've now changed this to nopull and that seems to have made a small difference. But I'm still seeing 930 uA on our board, vs ~140 uA on the dev kit.