Low Power Issues

piotr337 the UART interface uses a ton of current. In particular, the receiver uses the bulk of it. So if you can turn off the receiver when you’re not expecting data that will save you a bunch. If you need to leave it on at all times you may need to re-think how your device/application works.

I hope that helps!

If you have the console enabled you should disable the receiver for that as well.
Also make sure if you’re using GPIOs that they’re set to sense mode in your overlay.

&gpio0 {
    sense-edge-mask = <0xffff>;
};

The active_sleep sample is a place to start since it’s highly optimized. Also you’ll get higher than normal current if you feed the nRF9160 Feather with more than _4V

Sounds like you’re on the right track!

In my experience, with the modem in PSM and only one active gpio level interrupt, about 13µA are reachable.

I’m supplying the board with an input of 3.3VDC.

At the “BAT” input? If you use the PPK II, you may use that as current source which allows you also to adjust the voltage. In my experience, if BAT is above 4.1V, the quiescent current is increased. Not sure, if I remember that well, but below 3.5V, there is also some extra current. At BAT 3.3V you’re very close at the lower limit.

I use the ASYNC variant of UART so it’s hard to speak to any other version.

Ultimately, without seeing what’s in your overlay, code and what’s hooked up hardware-wise you’re a bit on your own @piotr337. I’ve spent a ton of time talking to Nordic and also trying to optimize myself. It’s almost always something silly.

For anyone who lands here in the future, I had a similar issue, so noting down my solution here:

I was seeing about 1mA consumption during sleep. However, loading the active_sleep example, i could see it get down to 6uA, so i knew it wasnt the board in question. After hunting for a while, i found that I was missing 3 things:

1) Pulling wp and hold (pins 8 and 9) up saves about 100uA:

.overlay:
\ { 
zephyr,user {
        wp-gpios = < &gpio0 8 GPIO_ACTIVE_LOW >;
        hold-gpios = < &gpio0 10sc GPIO_ACTIVE_LOW >;
    };
}

main.c:
static const struct gpio_dt_spec wp = GPIO_DT_SPEC_GET(DT_PATH(zephyr_user), wp_gpios);
static const struct gpio_dt_spec hold = GPIO_DT_SPEC_GET(DT_PATH(zephyr_user), hold_gpios);
...
void setup_gpio() {
  gpio_pin_configure_dt(&wp, GPIO_INPUT | GPIO_PULL_UP);
  gpio_pin_configure_dt(&hold, GPIO_INPUT | GPIO_PULL_UP);
}

1) Much more importantly, allowing control over the uart saves about 700 uA:

prj.conf
CONFIG_UART_ASYNC_API=y
CONFIG_UART_LINE_CTRL=y

3) Turning off the uart as mentioned above saves about 30uA

main.c

int setup_uart()
{

	static const struct device *const console_dev =
		DEVICE_DT_GET(DT_CHOSEN(zephyr_console));

	/* Disable console UART */
	int err = pm_device_action_run(console_dev, PM_DEVICE_ACTION_SUSPEND);
	if (err < 0)
	{
		LOG_ERR("Unable to suspend console UART. (err: %d)", err);
		return err;
	}

	/* Turn off to save power */
	NRF_CLOCK->TASKS_HFCLKSTOP = 1;

	return 0;
}

With this, even with the modem on in psm mode, i have 6uA in sleep. i chose to keep uart on (so not doing point 3) to ensure that we can always see what the device is doing, which means we average around 38uA in sleep right now.

Using the CONFIG_UART_ASYNC_API enables the driver to detect a “break” on RX (long low). Using that to trigger the suspend and adding a level interrupt to reenable the UART, you may keep the logs (when something is connected to TX/RX) and save the energy, if not (RX may be required to be pulled to low.)

See uart_manager.c for more details.

Thanks for sharing @JeppeMariagerLam. This has always been tricky.