nRF9160 current consumption / VDD_GPIO

RE: nRF9160 current consumption / VDD_GPIO

Sigurd Hellesvik — Thu, 20 Jun 2024 13:28:15 GMT

Hi,

I will continue to help with this ticket.

[quote user="Ilkka"]This should be OK? [/quote]

Yes, I think that should be okay.

[quote user="Ilkka"]I think actually the only peripheral I needed to take care of is uart[/quote]

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

[quote user="Ilkka"]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.[/quote]

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

RE: nRF9160 current consumption / VDD_GPIO

Hidastelija — Mon, 17 Jun 2024 12:15:22 GMT

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

RE: nRF9160 current consumption / VDD_GPIO

Simonr — Mon, 17 Jun 2024 09:18:44 GMT

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

RE: nRF9160 current consumption / VDD_GPIO

Hidastelija — Tue, 11 Jun 2024 12:06:37 GMT

We have an embedded soldered SIM module on the board, it is not easy to remove. However, we have verified the SIM operating voltage goes to 0V when the FW turns of the modem.

I have not tested a module without a SIM, but as a note not directly related. The current consumption is mA level if the FW will not use modem library to initialize the modem.

There are floating GPIOs, but I don't fully understand what do you mean. The are several gpio pins going out of the module, like in nRF dev kits the are open gpio pins on headers. They are not connected to anything and set up as not connected in the FW. Additionally there are connections between nRF53 and nRF91. nRF91 coex pins are connected to nRF53 like they are on Thingy91 and nRF91 also connects to nRF53 reset.

All nRF53 pins should be in reset state. nRF91 pins should be not connected except for SPI and I2C that are connected to the sensors.

RE: nRF9160 current consumption / VDD_GPIO

Naeem Maroof — Tue, 11 Jun 2024 08:08:05 GMT

Can you check with the sim card? probably remove it and see if it helps

Are there any gpio pins floating?