NRF9160 Deep Sleep Power Consumption Help

RE: NRF9160 Deep Sleep Power Consumption Help

Stian Røed Hafskjold — Fri, 10 Dec 2021 07:53:20 GMT

Thanks. So that's definitely not the regulator in refresh mode as I mentioned in my last reply. Looks like something is being polled every ~50ms. But, if the nRF91 CPU is waking up I would expect the current to be higher.

It could be the PWM. Is it enabled?

Are you sure the nRF91 is causing this? It could be an external sensor or similar, if you have that.

You are also welcome to send me your board for further debugging, but because of new covid regulations access to the office/lab is restricted at least the next two weeks, so it would have to wait probably until after Christmas. If you choose to do so please create a new private ticket and mention my name.

RE: NRF9160 Deep Sleep Power Consumption Help

TylerS — Thu, 09 Dec 2021 20:34:31 GMT

Ok, Thank you for the information. The fact that it would cause a 500-600 uA draw makes me think UART may not be the issue. Here is a rough capture of the best sleep current we have gotten so far where 1mv = 1uA:

It seems the lower level current is in the 300-400uA range. Most of this is likely caused by other peripherals on the PCB that are consuming power.

One other note is that we are using the SICA-B1A revision of the 9160. I am unsure if this new revision could change sleep current consumption etc.

Thanks,

Tyler

RE: NRF9160 Deep Sleep Power Consumption Help

Stian Røed Hafskjold — Thu, 09 Dec 2021 10:41:58 GMT

Hello

1. In the UART driver *_LOW_POWER, *_OFF and *_SUSPEND leads to the same code, which is disabling the UART:

https://github.com/nrfconnect/sdk-zephyr/blob/18e072b03270436fcd58312217fa8f362abb5ccd/drivers/serial/uart_nrfx_uarte.c#L1871

In the zephyr documentation they use the definitions "Device context is preserved/lost/may be lost, etc..". How this exactly translates in the peripheral hardware/low level driver depends on the type of hardware. In the case of the UART, it's either enabled or disabled. It would be nice to describe how this should be interpreted in the respective peripheral driver documentations. I will create a request for this.

2. You should expect to see about 600 uA less current consumption. If there is a periodic current draw every 50 ms I don't think it's the HF clock. Are you able to post any plots? If the current is in the <10uA range between the spikes and the current goes up to 500-600 uA every 50 ms I'm thinking that this is the regulator in refresh mode (burst mode). The regulator will always draw current in bursts during idle, and the average current including the bursts is what is relevant.

RE: NRF9160 Deep Sleep Power Consumption Help

TylerS — Fri, 03 Dec 2021 19:14:58 GMT

Hi Stian,

Thank you for the thorough response. It is very helpful. A couple of questions / clarification regarding your response:

1. You mention that in order to dynamically turn on and off UART we should be using the pm_device_state_set() function. I am still a bit confused about the exact states to use inside of the application. My understanding from your response is that we should first use pm_device_state_set(console, PM_DEVICE_STATE_OFF, NULL, NULL); to disable UART in the application until it is needed. Next to turn it back on we should change the state to: PM_DEVICE_STATE_ACTIVE. Lastly, in order to disable UART before sleeping we should change the state to: PM_DEVICE_STATE_SUSPENDED. Is this correct? I am a bit confused why we should use both the OFF state as well as the SUSPENDED state and why not just one or the other.

2. How much current consumption savings should we expect to see after disabling UART and therefore stopping use of the HF clock during deep sleep? Right now we are seeing a periodic current draw where there is about 500-600 uA of draw every 50ms or so. Trying to track that down and see if it is in fact the HF clock.

Thank you again for all of the help.

RE: NRF9160 Deep Sleep Power Consumption Help

Stian Røed Hafskjold — Wed, 24 Nov 2021 16:00:16 GMT

Hi, sorry for the late response.

[quote user=""]What is the real reason that turning serial off saves power in deep sleep? From looking at other tickets I think that the root cause of the power draw is keeping the HF clock active in deep sleep which can draw a decent amount of current.[/quote]

The UART, more specifically the UART receiver is using the HF clock constantly, because it is always ready to receive data. The UART peripherals are automatically enabled in zephyr, and thus also the UART receivers. This includes the logging module which is using UART0, but also UART1 and UART2, even though they may not be used at all. You will have to explicitly disable these peripherals if they are not used in the .overlay file.

Using CONFIG_SERIAL=n is a quick way to turn off all UARTs. But as you say, if you are actually going to use any of the UARTs, it can not be used. I would recommend to only use this config in the SPM config file, as this will turn off the logging module in the SPM, and then you can still use UART in the application.

The HF clock current does not add up when enabling several peripherals that are using the HF clock. So the current will stay at 5-600 uA and not go down until all peripherals requiring the clock are disabled.

[quote user=""]Are there other peripherals that could be causing the same issue for us still? We use I2C, SPI, UART, PWM, and GPIO in the application. [/quote]

I2C slave, GPIOTE IN event and SPI slave will use a pin sense mechanism which will consume current in the 20-50 uA range. The HF clock will only be started when there is a transaction. PWM and other "master" peripherals will only use the HF clock when they are active (as in ongoing transaction, or PWM output)

[quote user=""]What is the best way to have serial enabled in the application but turn the peripheral off before sleeping in NCS1.7.0 and mfw1.3.0?[/quote]

Power management API

The best way is to use the power management API:

Add CONFIG_SERIAL=n to the SPM prj.conf
Add CONFIG_DEVICE_POWER_MANAGEMENT=y to the application prj.conf
And the following to main in order to turn off logging (and UART0)

#include <pm/pm.h>

void main(void)
{
    const struct device *console;
    console = device_get_binding(DT_LABEL(DT_CHOSEN(zephyr_console)));
    pm_device_state_set(console, PM_DEVICE_STATE_OFF, NULL, NULL);
    
    .....
}

Then you can use the same pm_device_state_set() function to turn the UART1 or UART2 on or off dynamically. Use PM_DEVICE_STATE_SUSPENDED and PM_DEVICE_STATE_ACTIVE.

Using an overlay file

It's also a good idea to use an .overlay file to modify the device tree so that peripherals you are not using are disabled. Below is an example where UART1, UART2, and the receiving part of UART0 is disabled. Now UART0 is available for log output, but the receiver is switched off, which means that UART0 will not request the HF clock and neither will UART1 or UART2, so the current consumption should go down to about 50 uA which is the "enabled only" current for UART0. (Note: You can not disable UART0 completely using the overlay file, as this is used by the logging module, unless you disable the logging module in the config files)

The overlay file should be named the same as the board you are compiling for, and be put in the project folder. E.g. nrf9160dk_nrf9160ns.overlay

&uart0 {
    /delete-property/ rx-pin;
};
&uart1 {
    status = "disabled";
};
&uart2 {
    status = "disabled";
};

So to summarize:

CONFIG_SERIAL=n only in SPM project
Use power management API to dynamically power on/off the UARTs. The UART should not consume any current when suspended.
Use power management API to turn off logging module (UART0), if it's not needed.
Use .overlay file to disable unused peripherals.
Use .overlay file to turn off RX, of you are only using TX. In this mode the peripheral will consume about 50 uA, and you do not have to use the power management API if 50 uA is acceptable. You can use this method on the logging module (UART0)

RE: NRF9160 Deep Sleep Power Consumption Help

TylerS — Tue, 16 Nov 2021 22:37:09 GMT

Wanted to add a bit more flavor here, and a quick update. We have gotten the average current draw down to around 500uA by powering down some other SOC peripherals (Accelerometer etc.) I am using a "Current Ranger" to measure the current and hooked up my scope to grab the waveform while it is in deep sleep.

It seems like some internal system is periodically pulling maybe around 600uA or so at a period of about 25ms. Is this typical of some internal peripheral on the 9160?

We have also learned that mfw1.3.1 is what will be supported soon by the US carriers so we will be developing on this version going forward.