nRF9160 current consumption / VDD_GPIO

[Hidastelija]

Hi,

We are wondering the current consumption in our custom board. The board has the following components (my FW view :)

nRF9160 - powered directly from batteries (either rechargeable ~4V or primary ~3.6V)

3.3V DCDC regulator providing power for these:
+ nRF9160 VDD_GPIO
+ nRF5340
+ Lis2DH accelerometer
+ W25Q80DV SPI flash

We have individual current measurement pads for all these components and I've used Nordic PPK2 to measure current consumption. We have trouble understanding why the design draw so much current while nRF9160 modem is idle.

My assumption is that we should be under 15uA, when nRF5340 is power off and accelerometer and flash are in low power state. Actually, there are some days when I have been able to see current consumption around 15uA, but usually with the same FW the board draws ~55uA. When we dig deeper, we notice that the extra 40uA goes to nRF9160VDD_GPIO. All other components draw as much as expected, including nRF9160 VDDH.

In addition, 55uA is not the current consumption soon after nRF9160 modem is powered off. After data transmission the current consumption is about 20uA higher and the consumption is gradually over about 10 minutes going down to 55uA.

Do you have any idea what could be causing the high current consumption?

Kind Regards,
Ilkka

[Simonr]

Hi

Are you saying the nRF53 is in the reset state while this is occurring. If so it will be in an undefined state and thus that could be the current consumption you're seeing as well. A colleague of mine recommends checking how you configure your GPIO input pins, as we've seen similar issues when porting from the nRF9160 DK to other boards with buttons. There we found out using the  dk_buttons_and_leds library did the trick for custom boards as well.

Best regards,

Simon

[Hidastelija]

Hi Simon,

The nRF53 is not held in reset, the reset pin is released and the FW turns the app core off. The simple FW on the nRF53 is NCS sample nrf5340/empty_app_core with a modification:

CONFIG_BOARD_ENABLE_CPUNET=n

I've assumed that the power on reset state for all GPIO pins is input/disconnected as the documentation states that the reset value for PIN_CNF register is 0x00000002. To my knowledge this state is the lowest possible power state for a given GPIO pin. That being said, I'm actually not correct with the pins being in reset state. The sample sets GPIO control to CPUNET before going to hibernate.

About nRF9160 pins. Only those pins that are relevant to something are used in the FW. Rest of the pins are left to reset state. This should be OK? I've have tried to make sure that the pins that are left by mcuboot to a non-reset state are configured to low power in the application. I think actually the only peripheral I needed to take care of is uart. In the application I power down the uart using Zephyr power management:

pm_device_action_run(console, PM_DEVICE_ACTION_SUSPEND)

On the board we have a button and LEDs. They are available in the DT similarly as they are on nRF9160DK, but I think using the button or the leds had the kind of effect on current as expected. The button and LEDs were used like they are used in zephyr/samples/basic/button.

I will take a look at the dk_buttons_and_leds library and I will check with our HW designers and will do some more testing again.

Br,
Ilkka

[Sigurd Hellesvik]

Hi,

I will continue to help with this ticket.

Hidastelija said:

This should be OK?

Yes, I think that should be okay.

Hidastelija said:

I think actually the only peripheral I needed to take care of is uart

Yep, this is known. I think there is an issue or PR out there somewhere saying that MCUboot should clean up UART properly.

Hidastelija said:

I will take a look at the dk_buttons_and_leds library and I will check with our HW designers and will do some more testing again.

Looking forward to hearing about this!

One more thing:
Have you tried your code on a DK? Do you see the same current draw there?

Regards,
Sigurd Hellesvik