nRF9160 current consumption

RE: nRF9160 current consumption

Amanda Hsieh — Mon, 20 Apr 2020 11:29:07 GMT

Hi,

The 200µA could maybe be a GPIO that has internal pull up/down configured, and is being pulled down/up.

-Amanda H.

RE: nRF9160 current consumption

Meni — Thu, 16 Apr 2020 12:12:06 GMT

In general, I have a couple of threads that most of the time are all blocked by message queue.
At the beginning of each hour, the cpu wakes-up by RTC0 interrupt and one of the threads start sampling an analog input for 30 sec.
at the end of this process I disable all the relevant peripherals (UART2, SPI, I2C, SDADC).

once a day the cpu sends his calculation to web server and after that I turn off the modem by using lte_lc_power_off() api.

while all the threads are blocked, the kernel goes to IDLE state. At this time I want to disable the context switch and some peripherals.

I have a HW switch of all my HW components so basically they are all disconnected from power supply.

RE: nRF9160 current consumption

MJD093 — Tue, 14 Apr 2020 15:36:04 GMT

Ok, I think I need more information about your application.

Is your main() function looping or can your application fall straight through and work off of work queues and other threads?

If it doesn't then this won't work. This assumes that there are no threads that are ready to run including the main thread and therefore the kernal scheduler is IDLE.

Your application being IDLE and the kernal scheduler being IDLE are two very different things.

For the power consumption, have you any figures for how much current drain your device makes from other parts of the device. There could be consumption from other things on your device. Also, to get lower consumption then you need to disable more than just UART0.

RE: nRF9160 current consumption

Meni — Tue, 14 Apr 2020 15:29:28 GMT

According to the following link:
docs.zephyrproject.org/.../index.html

When the device becomes idle for at least CONFIG_TICKLESS_IDLE_THRESH ticks, the OS context switch should be disabled.
In this state, I want to disable UART0 debugging port etc'.

There for I turned on the flags:
CONFIG_TICKLESS_IDLE=y
CONFIG_TICKLESS_IDLE_THRESH=3
CONFIG_SYS_POWER_SLEEP_STATES=y

In that case the user API's:

void sys_pm_notify_power_state_entry(enum power_states state)
void sys_pm_notify_power_state_exit(enum power_states state)

should be called by the OS, but for some reason it does not happen.

In any case, even when I disable all peripherals (including UART0) i am getting 200uA
And I can't find the reason for that.

RE: nRF9160 current consumption

MJD093 — Tue, 14 Apr 2020 14:13:30 GMT

I'm not sure what you mean? How exactly are you 'sleeping' the device?

The module can go very low (I've measured 7uA on the Development Kit) in a low power IDLE state. However, it is your own code that is managing the application, including the IDLE state. I'm not sure why you would need hook functions.

Your custon FW manages how the device transitions different states, so you wouldn't hook anything. Just invoke some additonal features in your state transitions to disable/enable some peripherals.

RE: nRF9160 current consumption

Meni — Tue, 14 Apr 2020 14:03:18 GMT

Are there any hooks functions that invoke while the device enters and exits from sleep mode?

RE: nRF9160 current consumption

MJD093 — Tue, 07 Apr 2020 11:48:55 GMT

The simplest way to reduce the current is to disable the unused peripherals that are not necessary when in IDLE.

What systems are incapable of being used in IDLE should be disabled during runtime using code such as:

printk("Disabling SPI\n");

NRF_SPIM3_NS->TASKS_STOP = 1;
NRF_SPIM3_NS->ENABLE = 0;

Refer to the user manual on peripherasl to see how to do this with the other ones. Be sure to write code that can re-enable them as well as disable.

For other systems, consider smarter ways to incorperate them. Such as; when IDLE, disable all peripherals and enter low power IDLE. If interrupt pin triggers, re-enable only the perpiherals required to deal with that interupt.

UART0, serial port should be disabled if it is not being used for debugging to further reduce the power consumption, (this usually drains several hundred uAs).