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.

[Jørgen Holmefjord]

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

[Rory Morrison]

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

[Jørgen Holmefjord]

Hi,

Rory Morrison said:

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

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.

Rory Morrison said:

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.

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.

Rory Morrison said:

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.

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.

Rory Morrison said:

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?

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

Rory Morrison said:

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?

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

[Rory Morrison]

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

[Jørgen Holmefjord]

Rory Morrison said:

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?

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.

Rory Morrison said:

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.

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.