nrf9160 drawing high current

jessemorris

Hi CircuitDojo Community,

I’m working on the nrf9160 to be used as a remote device to enable/disable other power systems and is connected to a small battery. When testing current draw using the configuration and following the instructions here (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_power_opt.html) the device draw an average of 7.65ma when running the blinky script, rather than the 600 µA suggested. Turning off serial logging also had a negligible effect on the current draw. Following your other “low power” scripts also seemed to have no effect and the current remained around 7.65ma.

Currently, I do not have the external development chip and so am flashing the chip with CONFIG_BOOTLOADER_MCUBOOT=y using the terminal command “newtmgr -c serial image upload build/zephyr/app_update.bin”.

Any suggestions as to why this is occurring or what to test/investigate would be much appreciated.
Jesse

CMakeLists.txt:

# SPDX-License-Identifier: Apache-2.0

cmake_minimum_required(VERSION 3.13.1)

# Adding custom overlay to add settings that aren't included in the SDK (yet) for the nRF9160 Feather
if(${BOARD} STREQUAL circuitdojo_feather_nrf9160ns)
message(STATUS "Adding .overlay for mcuboot.")
list(APPEND mcuboot_DTC_OVERLAY_FILE
  "${CMAKE_CURRENT_LIST_DIR}/conf/mcuboot/circuitdojo_feather_nrf9160ns.overlay"
  )
endif()

find_package(Zephyr HINTS $ENV{ZEPHYR_BASE})
project(blinky)

target_sources(app PRIVATE src/main.c)

prj.conf:

CONFIG_GPIO=y

# Enable Zephyr application to be booted by MCUboot
CONFIG_BOOTLOADER_MCUBOOT=y

overlay

/ {
	aliases {
		bootloader-led0 = &blue_led;
    };
};

// Full speed ahead
&uart0 {
	status = "okay";
	current-speed = <1000000>;
	tx-pin = <6>;
	rx-pin = <5>;
};

src/main.c -> the default blinky main

jaredwolff

Hey jessemorris

What version of the board do you have?

One thing you can do is disable the rx-pin if you’re not using bidirectional logging. Any time you leave the receiver on for a UART it draws about 1mA (per UART). You can also disable it in software using the power management API.

jessemorris

jaredwolff

Hey Jared, the board version is: BRD-0015-02.
Another question - what should the power draw of the feather be in low power mode in an ideal, optimized state?

jaredwolff

jessemorris while you can get lower, the older boards only support low current shutdown using the external RTC. The latest boards should active sleep < 100uA.

tedhavelka66 thanks for adding those tips. 😀

tedhavelka66

Hello Mr. Morris,
Your post caught my eye as I am facing nearly the same issue on an nRF9160 based custom board. I posted an initial set of questions on this issue here at CicruitDojo Forum a few weeks ago, and Jared helped me with some run-time code which, in an nRF9160 + Zephyr RTOS context puts UART devices into a suspend mode. This is a low power mode which disables the high frequency clock of the 9160’s ARM application core, the Cortex-M33.
In my firmware project I have been able to reduce average current draw down to about 85uA, by suspending the two UARTs which would normally be in use while the product’s firmware is running in a functionally active state. We’re battery powered also, and are relying / hoping/ praying to reach the nRF9160’s specified 1.4uA lowest current consumption. I will be posting a new set of questions here shortly as I’m running into a couple of brick walls to drawing lower current than I can presently reach.
In case it is of interest to you, here is a code snippet where I declare a local pointer to a Zephyr device, in this case Zephyr’s chosen console UART, and then call a Zephyr API function to manage its power state:

const struct device *console; console = device_get_binding(DT_LABEL(DT_CHOSEN(uart0))); rstatus = pm_device_state_set(console, PM_DEVICE_STATE_SUSPEND, NULL, NULL);

On review here I have neglected to check whether my pointer *console is null or not, and that would likely be a best practice. But I have confirmed in a Nordic Devzone post reply dated 2022-03-21 that I am successfully suspending the UARTs on my hardware. Otherwise Devzone engineer tells me I would measure about 500 microamps or higher, not 85 microamps.
A final note, I am sure you have turned off any LEDs in your low power firmware tests (you mention running a “blinky script”). In our hardware, even the red LED draws about 1mA current when on. I believe blue LEDs draw more.
I’ll bookmark your post so I may follow along and see what solution you find. I hope we can get to the bottom of each of our mystery power consumption issues in our nRF9160 designs!