nRF5340 SAADC power consumption

RE: nRF5340 SAADC power consumption

Rory Morrison — Wed, 07 Dec 2022 15:58:49 GMT

Thanks Jørgen, that's really helpful.

I've tried my interrupt test code on the dev kit, and now get something like I was getting on our custom hardware.

Without the Signal Generator connected, I get ~18 uA with a spike every second when the CPU wakes up and immediately goes back to sleep. That's pretty much what I expect, although I'll double check the current figure.

With the sig gen connected and at 1000 Hz, I get about 580 uA, with the same sort of 3 mA spikes as I was getting before - except these are at 1 kHz, which matches the sig gen.

Zoomed in it looks like this

So it looks like I get similar behaviour on the dev kit to what I get on our own board. But the spikes are at a lower frequency, so the overall current consumption is a bit lower.

ETA: current consumption increases even more if I change the gpiote interrupt config - In my test code I had set the pullup to NRF_GPIO_PIN_NOPULL and hi_accuracy to false while trying to get to the bottom of the current draw.

Setting the pull back to NRF_GPIO_PIN_PULLUP I'm now getting just under 650 uA, and setting high accuracy mode to true it jumps to 1.4 mA.

One thing I want to check with you though - I've now cut both SB 40 and SB 41, I assume I need to put a jumper across whichever one I'm not using to power the nRF53?

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Wed, 07 Dec 2022 14:01:15 GMT

Hi,

I have not done much current measurements in high voltage mode, but what worked for me was to put the "nRF power source" switch in USB position, cut SB41 (VDD_HV) on the DK, then connect Vout from PPK2 to the upper pin of VDD_HV, the GND pin from PPK2 to "-" pin of external supply, then set the PPK2 application in source meter mode. All other switches are in default positions.

Could you check if this works on your end as well? It could be beneficial to program a BLE example or similar to the board until you get the current measurements working correctly, then you can see the spikes when the radio is active (for instance at the advertising or connection interval).

Best regards,
Jørgen

RE: nRF5340 SAADC power consumption

Rory Morrison — Tue, 29 Nov 2022 12:24:11 GMT

Can you talk me through how to measure the power consumption via the external supply? So far the only way I've managed to get sensible current measurements off the Dev Kit is using the PPK in source meter mode, and powering the nRF chip via the current measurement pin following this method.

If I want to use the PPK in Source Meter mode to measure High Voltage mode, it looks like I can just connect VOut on the PPK to + and GND to - on the external voltage pins, but then I'm not sure what to do with the nRF POWER SOURCE switch, the POWER on/off switch, and the two micro-switches on the bottom of the dev kit (VEXT->nRF and nRF ONLYDEFAULT).

I'm getting more-or-less what I expect if I set VEXT->nRF to off, and nRF ONLYDEFAULT to what I think is on (switch is to the left, where the dot is). Then power and power source don't seem to make any difference, and I get ~3.5 uA when the CPU is in sleep mode (as in, the main function exits, no tasks or interrupts configured).

Does that sound right? If so, I can try again with different test code and see if I can reproduce the same ~900 uA current draw.

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Mon, 28 Nov 2022 16:43:48 GMT

Hi,

Have you tried running the DK in high-voltage mode (through nRF_USB or external supply), to see if you see the same current consumption there? See nRF5340 power source.

I will check with our current experts if they have seen something like this. Could you share your schematics for reference?

Best regards,
Jørgen

RE: nRF5340 SAADC power consumption

Rory Morrison — Wed, 23 Nov 2022 16:23:19 GMT

Hi again - I've found another key bit of information.

Our board powers the nRF5340 in High Voltage mode, whereas the dev kit is in low voltage mode. We're then powering some of our peripherals off the chip's VDD at 1.8 V.

Even with all the external chips removed, and putting in a clock signal from the signal generator into our board, I'm still getting hundreds of uA more than I do on the dev kit.

However, by connecting the PPK directly to VDD and bypassing the HVREG entirely, I get dramatically lower current - comparable to the dev kit.

So it seems either we've done something very wrong in how we've powered the board for HV mode, or the HV regulator is doing something very wrong.

As I understand it, all we need to do to be in HV mode is power the chip through the VDDH pin, is that correct?

RE: nRF5340 SAADC power consumption

Rory Morrison — Mon, 21 Nov 2022 17:02:08 GMT

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.

RE: nRF5340 SAADC power consumption

Rory Morrison — Thu, 17 Nov 2022 17:12:33 GMT

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?

RE: nRF5340 SAADC power consumption

Rory Morrison — Tue, 15 Nov 2022 10:45:33 GMT

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.

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Fri, 11 Nov 2022 12:46:26 GMT

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?

RE: nRF5340 SAADC power consumption

Rory Morrison — Tue, 08 Nov 2022 11:35:19 GMT

Okay, this is the project.devzone.nordicsemi.com/.../minimal_5F00_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.

RE: nRF5340 SAADC power consumption

Rory Morrison — Tue, 08 Nov 2022 10:59:55 GMT

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

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Tue, 08 Nov 2022 10:03:44 GMT

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

RE: nRF5340 SAADC power consumption

Rory Morrison — Fri, 04 Nov 2022 15:06:23 GMT

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

RE: nRF5340 SAADC power consumption

Rory Morrison — Tue, 01 Nov 2022 12:16:13 GMT

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?

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Tue, 01 Nov 2022 11:20:17 GMT

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

RE: nRF5340 SAADC power consumption

Rory Morrison — Wed, 26 Oct 2022 13:32:59 GMT

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);

RE: nRF5340 SAADC power consumption

Rory Morrison — Mon, 24 Oct 2022 16:42:37 GMT

Hi Jørgen,

I tried doing that last week, and although it stopped the ISR being called, it didn't make much difference to the current (maybe 10 uA or so, but in context of >900 uA of current that's not a lot).

So I went back through my code just commenting things out bit by bit to try to confirm exactly what part of enabling it was causing all the current draw. It turns out even initialising the interrupt causes a much higher current.

Today I've been looking at the basic button sample project to confirm if the interrupt is still a problem without any of our code involved. Initially that was drawing 833 uA. I got that down somewhat to 632 uA by removing the LED code and changing it to use GPIO_INT_LEVEL_ACTIVE instead of EDGE_TO_ACTIVE to trigger the interrupt. But while searching for ways to reduce the GPIO interrupt power consumption I found for example this where they're complaining about a 100 uA current. So it still seems way too high.

I've added a k_msleep call before doing anything in the button sample code, and I can see that's got a current consumption of about 22 uA. So that implies it's not anything on our board drawing excess power. And I've confirmed the interrupt doesn't get triggered, so it's also not that the sample code is connected up to some floating voltage and getting triggered at random, so it seems to be genuinely a sleep current of hundreds of micro amps just from enabling the interrupt.

The sample code is using different API code as it's using the gpio module, not nrfx_gpiote, and it seems to be using PORT not PIN events. So that might explain why it was at 833 initially not 900+ as in our main project.

But I think it should be much much lower than that. Looking again at the current consumption figures, it looks to me like it should be in I_{ON_IDLE4}when waiting for an interrupt, which is 48 uA. What I'm wondering is if somehow it gets stuck in I_{ON_IDLE3,128MHz}which is 785 uA, and the only thing I can see close to the power consumption I'm getting.

Thanks,

Rory

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Wed, 19 Oct 2022 16:00:43 GMT

The second argument to nrfx_gpiote_in_event_enable() determines if the interrupt is enabled or not. If you set that to false, the pin should not generate interrupts.

RE: nRF5340 SAADC power consumption

Rory Morrison — Wed, 19 Oct 2022 14:37:52 GMT

These are the actual SDK calls we're making, I've pulled them together from various files in our project but I think this covers all of it:

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(KHZ_CLOCK_PIN, &pin_interrupt_config, dummy_handler);
nrfx_gpiote_in_event_enable(KHZ_CLOCK_PIN, true);

uint32_t clock_event_address = nrf_gpiote_event_address_get(NRF_GPIOTE, nrfx_gpiote_in_event_get(KHZ_CLOCK_PIN));

uint32_t task_address = nrf_saadc_task_address_get(NRF_SAADC, NRF_SAADC_TASK_SAMPLE);

ppi_init_channel_one(clock_event_address, task_address);

and dummy_handler passed in to the init function is an empty function.

I did just remember we were previously calling nrfx_gpiote_in_init with NULL instead of a callback handler, but when I updated to SDK 2.1.0 that started causing a hard fault as the SDK was attempting to execute NULL.

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Wed, 19 Oct 2022 12:19:42 GMT

[quote user="isansys_rory"]I assume this is because either way the interrupt wakes the MCU to take a sample or generate a PPI event so we get more or less the same current draw. Is there an alternative way to generate a PPI event from a pin toggle without waking the MCU?[/quote]

Can you post the code you used to configure the GPIOTE pin? Interrupt should only happen if interrupt for the GPIOTE channel is enabled in the code.

[quote user="isansys_rory"]

I did look at changing to a PORT event - am I right in thinking that's set by the hi_accuracy config option in the

nrfx_gpiote_in_config_t struct? I tried setting that to false and it didn't make much of a difference, in fact increasing the current draw by 5-10 uA if I remember correctly.

[/quote]

If the CPU wakes up to handle an interrupt for every GPIO toggle, this will likely cause the majority of the current draw. When the GPIOTE PORT event is used with the GPIOTE driver, the driver will have to check the state of each pin in SW, which will likely cause the interrupt to take a bit longer to complete. If this should give any improvement, you would have to connect the PORT event directly to the PPI channel, and disable any interrupts for the PORT event in the GPIOTE peripheral and driver. Like I said before, this will prevent you from using the PORT event for other GPIOs, and you should only enable GPIO sense for the GPIO that should trigger the sampling.

RE: nRF5340 SAADC power consumption

Rory Morrison — Wed, 19 Oct 2022 11:02:52 GMT

Hi Jørgen

I've not got much further with this, but from experimenting a bit with sampling in an interrupt, I've found that our current draw is mostly from the interrupt firing - even with the ADC off and an empty function for the ISR the current still jumps by about 1 mA. (~350 uA goes to ~1.33 mA)

I assume this is because either way the interrupt wakes the MCU to take a sample or generate a PPI event so we get more or less the same current draw. Is there an alternative way to generate a PPI event from a pin toggle without waking the MCU?

My other thought is perhaps there are settings in zephyr governing sleep that I could tweak so the MCU goes back to sleep quicker?

I did look at changing to a PORT event - am I right in thinking that's set by the hi_accuracy config option in the

nrfx_gpiote_in_config_t struct? I tried setting that to false and it didn't make much of a difference, in fact increasing the current draw by 5-10 uA if I remember correctly.

Thanks,

Rory

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Thu, 13 Oct 2022 14:05:46 GMT

Hi,

[quote user="isansys_rory"]We haven't changed the core clock, although from what I've found this morning it looks like it should default to 64 MHz.[/quote]

Yes, looks like this is correct. As long as you have verified that the application does not change it, this should not be the problem.

[quote user="isansys_rory"]We have an external RTC with a 32.0 kHz crystal to give us an exact 1kHz clock signal, which we're using via a GPIOTE interrupt to trigger the PPI task for sampling.[/quote]

I assume you then are using the GPIOTE IN event, and not the PORT event? Due to this errata, it is not possible to use the LowPower setting for the GPIOTE IN event: GPIOTE with low-power latency setting does not register IN events in System ON IDLE. The LowLatency option will give higher current consumption, but according to I_{ON_IDLE4}in Sleep current, this should not account for all the high current you are seeing. If you do not use the PORT event for any other GPIOs (like buttons, etc), it would also be possible to connect this to the PPI channel for a 1 kHz signal.

[quote user="isansys_rory"]The logic is that an internal RTC would either run on the HF clock thus requiring the HF oscillator to be on at all times, burning more power, or it would run on the LF clock at 32,768 Hz and we'd need to apply a correction to get exactly 1000 samples a second instead of 1024.[/quote]

Yes, you are correct here. The RTC runs off the 32.768 kHz LFCLK and you will only be able to get 1024 or ~993 samples per second using this clock.

[quote user="isansys_rory"]Is it possible to run an internal RTC from an external clock source on the Nrf53, and would that be more power efficient than using a GPIOTE interrupt?[/quote]

The LFCLK or RTCs does not have support for external clock sources in nRF5340.

[quote user="isansys_rory"]Or might it be that for some reason the SAADC/PPI is keeping EasyDMA on between samples, and therefore just taking a single sample in an ISR would be better, as we could turn everything off between samples?[/quote]

This was the case in nRF52 series, but I'm not 100% sure if this have changed in nRF5340. I will try to write a low power sample using PPI (without any stopping of the SAADC between sampling) to verify this.

Best regards,
Jørgen

RE: nRF5340 SAADC power consumption

Rory Morrison — Thu, 13 Oct 2022 11:56:16 GMT

Hi Jørgen,

We haven't changed the core clock, although from what I've found this morning it looks like it should default to 64 MHz.

We have an external RTC with a 32.0 kHz crystal to give us an exact 1kHz clock signal, which we're using via a GPIOTE interrupt to trigger the PPI task for sampling. The logic is that an internal RTC would either run on the HF clock thus requiring the HF oscillator to be on at all times, burning more power, or it would run on the LF clock at 32,768 Hz and we'd need to apply a correction to get exactly 1000 samples a second instead of 1024. (Of course some of that logic may be wrong as it was based on our experience with a different MCU).

Is it possible to run an internal RTC from an external clock source on the Nrf53, and would that be more power efficient than using a GPIOTE interrupt?

Or might it be that for some reason the SAADC/PPI is keeping EasyDMA on between samples, and therefore just taking a single sample in an ISR would be better, as we could turn everything off between samples?

Thanks,

Rory

RE: nRF5340 SAADC power consumption

Jørgen Holmefjord — Thu, 13 Oct 2022 09:19:55 GMT

Hi,

The LPOP options should not have been included in the product specifications, as this is an internal-only option. The LPOP is by default set to LowPower, and it should not be necessary to change this in the application. This will be fixed in the next release of the nRF5340 PS.

Have you changed the application core's clock from 128 MHz to 64 MHz, as described under "Voltage and frequency scaling" in System ON mode? Not doing this will increase the System ON sleep current significantly, as you can see in Sleep.

When you say that the sampling is triggered by an external clock, do you use GPIOTE for triggering this? Have you tried triggering it using the internal RTC?

Best regards,
Jørgen