Low Power Issues

piotr337

I think I’m stuck when it comes to low power on the nRF9160 Feather. I believe this is the V5 since I just purchased it.
I’m currently reading 1.4mA in my application. I’ve followed along with a lot of posts here and can’t seem to get the power usage down any further.
I configured PSM to the lower active time and that appears to have helped in that I can see the modem quiet down after some seconds.
I’m also now using the k_cpu_idle() call since the code doesn’t have to do anything until it gets an RX interrupt to process a request from my other MCU.
I don’t have any peripherals defined in my prj.conf file so based on your video on power, I don’t think I need to do anything in the code. I also copied the prj.conf from active_sleep that disables console, logging and debug.

As a test I disabled uart2, which I’m using for communication with an external MCU, and that got me down to 936uA. But I don’t think that’s feasible since I need to be able to communicate. (I did see a post somewhere on the nordic site where someone changed the RX pin to a GPIO and used it as an interrupt, but that seems a bit risky in my situation.)

Is there anything else I need to be aware of that would consume 936uA while the nRF9160 is essentially idle?

I’d appreciate any help.

Thanks!

jaredwolff

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!

piotr337

Yea I noticed that it uses about 500uA, that’s why I disabled it during a test run. I had a though of using an interrupt via a GPIO to “wake” the feather which would signal for me to turn on the UART to receive.

After disabling it, I’m still curious why at idle I’m still consuming about 936uA. When I run the active_sleep I measure about 136uA.

Are there any other peripherals that are on by default that I need to disable?

jaredwolff

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

piotr337

I disabled the console. And disabled both UART0 & 1 just in-case in the code.
NRF_UARTE1_NS->ENABLE = 0; NRF_UARTE0_NS->ENABLE = 0; NRF_UARTE2_NS->ENABLE = 0;

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

I also added the Zepyth Power Management in my prf.conf just in-case it needs this to do their own management when the board is idle:
# Zephyr Device Power Management CONFIG_PM_DEVICE=y CONFIG_PM=y

Also disabled all these features:
CONFIG_DEBUG=n CONFIG_CONSOLE=n CONFIG_UART_CONSOLE=n CONFIG_BOOT_BANNER=n CONFIG_PRINTK=n CONFIG_LOG=n

piotr337

I started work from the active_sleep example and now I’m getting more expected idle behavior at approximately 123uA.
I also see a drastic increase when using the UART with Interrupts.
So I’m trying to re-architect how I plan to use the UART.

jaredwolff

Sounds like you’re on the right track!

AchimKraus

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.

piotr337

Yes, at the BAT input.

The application is approximately 130µA with my one GPIO interrupt during idle state. I was able to add the interrupt driven GPIO to tell the nRF9160 to turn on the UART. I plan to disable it once I’m done receiving.

So I’ve pretty much isolated the issue. It has to do with the interrupt driven UART.

CONFIG_UART_INTERRUPT_DRIVEN=y

This balloons the consumption close to 1mA and I’m unable to reduce power using the following code:

int disable_uart()
{
	int err;

	/* Initialize the UART module */
	if (!device_is_ready(uart_dev2))
	{
		printk("Cannot bind UART device\n");
		return -EIO;
	}

	/* Power off UART module */
	uart_rx_disable(uart_dev2);
	k_sleep(K_MSEC(100));
	err = pm_device_action_run(uart_dev2, PM_DEVICE_ACTION_SUSPEND);
	if (err)
	{
		printk("Can't power off uart: %d\n", err);
		return err;
	}
        return 0;
}

This does disable the UART, as I can’t receive and the the interrupt never fires but the power remains high.

So I’m stuck at this last hurdle, because otherwise the system functions as I want it to.

AchimKraus

I’m not sure, what causes the high consumption.
I see two differences compared to my app/experience.

uart_rx_disable(uart_dev2);

I only use

pm_device_action_run(uart_dev2, PM_DEVICE_ACTION_SUSPEND);

3.3V

I use 3.6-4.0V.

And , of course, if you use a additional UART, sometimes the connected stuff causes that extra consumption. maybe a pullup and a low gpio or something like that. So, is it possible to remove any extra parts in order to see the resulting consumption?

piotr337

I’ll give it a try be removing uart_rx_disable(uart_dev2) and only uisng the pm_decice_action_run() function.

I converted my application to using the polling UART and it’s not as good as the interrupt driven method.

For some reason I was having issues with the ASYNC version this weekend. I may want to go back and explore that method instead of basic polling.

jaredwolff

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.

piotr337

OK I believe I’m successful. Now when the Feather is cpu_idle with the uart disabled like @jaredwolff has in his example, I’m down to 61µA.

In the overlay I added this particular line:

&uart0 {
	status="disabled";
};

Once I had that in there I can enable/disable uart2 and I see the power impact having the UART on.

Thank you @jaredwolff and @AchimKraus for supporting me.