Increased power usage for SAADC when migrating from nRF Connect 2.6.2 to 3.1.1

[Shawn S]

I have an application running on a custom board using the nRF52840 that uses the SAADC. After migrating my nRF Connect version from 2.6.2 to 3.1.1 the current draw of my battery operated device increased from about 15 uA to about 800 uA. I am using the PPK2 to measure the current. If I disable all calls to "adc_read" then the current used is in the expected range. It seems as though the ADC is no longer being suspended properly after each call to adc_read.

I can see that the nrf52840.dtsi file has the line "zephyr,pm-device-runtime-auto;" added to the ADC hardware definition. Does this mean I now need to use the "pm_device_runtime_get" and "pm_device_runtime_put" calls before/after the call to adc_read?

[Einar Thorsrud]

Hi,

I see the same on my end when comparing the current consumption of the adc sample in 2.6.2 with the adc_dt sample in 3.1.1. You should not need to add code to your ADC handling the runtime device management, but you need to enable device runtime power management with these two configs:

CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y

For reference, I tested with the unmodified sample except for adding these configs to get the base current without UART, as this is enabled by default and that maks this issue:

CONFIG_ADC=y
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=4096
CONFIG_SERIAL=n
CONFIG_UART_CONSOLE=n

[Shawn S]

Thanks Einar. I tried setting the CONFIG_PM_DEVICE_RUNTIME config to yes, but that did not help in my case. My code is more similar to the adc_sequence sample, in which adc_read is used instead of adc_read_dt. I wasn't able to get the adc_sequence sample running on my custom board, but I did get the adc_dt sample working, and confirmed that the power management was working properly. In the end what I did was convert my project code to use adc_read_dt by following the adc_dt sample as a guide. It is all working fine now.

I have a couple of questions. First, it doesn't seem like it makes a difference to the current draw on my board whether I include the CONFIG_PM_DEVICE_RUNTIME line in prj.conf or not include it. Is there a file that I can check to see what the final values are for all of the configuration settings? The second question is, can you check whether the adc_sequence sample has increased power usage in nRF Connect 3.1.1 versus 2.6.2? I'm wondering if a problem with adc_read was introduced at some point.

[Einar Thorsrud]

Hi,

I am glad to hear you got the idle power consumption down.

Shawn S said:

s there a file that I can check to see what the final values are for all of the configuration settings?

Yes, you can see the generated .config. Note that with sysbuild there are several .configs generated, and the one that is interesting is the one in the sub-folder for the project you are interested in in the build folder. So for instance if I build the peripheral_uart Bluetooth sample in place, the relevant .config file to look at is nrf/samples/bluetooth/peripheral_uart/build/peripheral_uart/zephyr/.config

Shawn S said:

The second question is, can you check whether the adc_sequence sample has increased power usage in nRF Connect 3.1.1 versus 2.6.2? I'm wondering if a problem with adc_read was introduced at some point.

You are right, I do not immediately see the cause for this but will look into it.

[Shawn S]

I have confirmed that the power usage is different using the 3.1.1 SDK and the 2.6.2 SDK for the adc_sequence sample. I used the adc_sequence sample from the 3.1.1 SDK and made two different builds for the nRF52840 DK (one for each SDK). With the PPK2 profiler, I see an average of 6.7 uA with SDK 2.6.2 and 1.08 mA with SDK 3.1.1.

The only change I made to the sample was to change the prj.conf file, which now looks as follows:

CONFIG_ADC=y

CONFIG_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_SERIAL=n

[Einar Thorsrud]

Hi,

I am sorry for the late update. I see the same on my end and is looking into it. There was significant updates to the driver in 3.1, and I am not able to reproduce with 3.0.2. I will continue to look into this and update here.