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]

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.

[Rory Morrison]

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?