Zephyr/nRF Connect on custom board - 20 microamps in ksleep()

[Christian Holland]

Hi, 

I am using Zephyr to do some action in a main loop and ksleep for 30 seconds. While in ksleep(), I can see that the consumption is 20ua. The board is a very small simple board which only has a button and four LEDs on it. The LED's are off in ksleep. Things that I have tried:

1) Turned off UART

2) CONFIG_SERIAL = n

3) Turned off debug/logging and disconnected debug tools (JLINK) and power cycled

4) The code advertises in BLE before the ksleep, but i make sure to shut down advertising before sleeping by running  bt_le_adv_stop();

What could be causing it?

[Einar Thorsrud]

Hi,

A current consumption of 20 uA is not a number that I would expect for system ON. Normally you should see 2-4 uA, and using additional non-low-power peripherals would increase it significantly more than up to 20 uA. Could it be that this is caused by other components on your board? If not, can you test a simple test firmware that does nothing other than sleeping, and check if you get comparable current consumption on the DK and your custom board? What do you measure then?

[Christian Holland]

Thanks - appreciate your quick response.

I have attached the schematic for my custom board for your reference - you'll see it's very simple.
I have adapted the Hello World example so that it simply goes to ksleep for 90 seconds. Here is the code i ran (sorry i dont see a way to format this into code):

#include <zephyr.h>

#include <sys/printk.h>

#include <hal/nrf_uart.h>

#include <hal/nrf_uarte.h>

void main(void)

{

  printk("Hello World! %s\n", CONFIG_BOARD);

  nrf_uarte_enable(NRF_UARTE0);

  while(1) {

    k_sleep(K_MSEC(90000));

  }

}

And here is my prj.conf:

CONFIG_SERIAL=n

I see a constant usage of 13-15 microamps using this code. This is less than my original code, so there is something that I need to turn off in that one i guess, but it is still not the 2-4uA that you mentioned. It is very difficult to get an accurate consumption reading from the DK because I can't isolate parts of the circuit that I need to, and after speaking to a Nordic engineer before, this involves desoldering etc which I don't really want to do

Schematic_1_0.pdf

[Christian Holland]

Hi einar, I have just seen the typo in my code in hello world:

Christian Holland said:

nrf_uarte_enable(NRF_UARTE0);

This should be disable. When disabling it, I am reading 2.4ua in ksleep, which is a normal reading. 

Therefore based on this we know that it is not the hardware causing the issues. But I can confirm that I disable uart in the same manner in my original code, so that is not the cause of the high usage there...

[Einar Thorsrud]

I see. Good to know the HW is OK.

The value of the current consumption itself does not give much hint, so I suspect the fastest way to narrow this down is to gradually comment out more and more of your code (initializing and uninitializing less and less to see at what point you no longer see the unexpected current consumption. That way you should fairly quickly see what parts is related to the high current consumption.

[Andrew Porter]

Hi - Simply adding MCUBOOT to the hello_world project config increases power consumption by ~10ua but the consumption then continues to rise, seemingly indefinitely.

[Einar Thorsrud]

Hi,

Is this the same situation as in the original question? nRF52832? Which nRF Connect SDK version are you using?

[Christian Holland]

Hi, yes andrew is working on this with me - i have been testing many situations and have found that MCUMGR/MCUBoot being enabled is increasing consumption by around 10ua. I was using zephyr 2.3.99, and i'm pretty sure it's the latest NCS version - how can i check?

[Christian Holland]

Hi Einar,

In order to test this scenario, I have fully upgraded to the very latest NCS version, and can confirm this issue persists. Please can you try to reproduce it to confirm my suspicions? Here is how:

1. Adapt the "Hello World" Zephyr sample to turn off uart, and have a while loop with a sleep:

   #include <zephyr.h>

   #include <sys/printk.h>

   #include <hal/nrf_uart.h>

   #include <hal/nrf_uarte.h>

   void main(void)

   {

     printk("Hello World! %s\n", CONFIG_BOARD);

     nrf_uarte_disable(NRF_UARTE0);

     while(1) {

       k_sleep(K_MSEC(30000));

     }

   }

2. Add CONFIG_SERIAL=n to prj.conf, and monitor the consumption. It should use around 2-3ua in ksleep.
3. Add CONFIG_BOOTLOADER_MCUBOOT=y to the prj.conf. You will see it uses at least 11ua in this scenario

[Einar Thorsrud]

Hi,

I am not able to reproduce this on a DK when I test the hello world sample from NCS 1.3 with your changes. Regardless of using mcuboot or not ("CONFIG_BOOTLOADER_MCUBOOT=y" in prj.conf commented or not), the current consumption is the same at about 2-3 μA. Are you able to reproduce this on the DK, or only on your custom board?

[Christian Holland]

Hi, sorry for the late reply I have been doing some in-depth testing.

We have found that, after adapting our current project to do the same as this, we are seeing the same results as you. However, when running the below line when setting up an interrupt on the button pin, it increases the consumption by about 17ua:

gpio_pin_interrupt_configure(button, SW0_GPIO_PIN, GPIO_INT_EDGE_TO_ACTIVE);

In order to test this, I span up the basic button sample from Zephyr, and can see that the consumption on this is very high too (after disabling uart and bringing the main loop sleep to 30 seconds). It seems that this function call increases consumption - are you seeing the same?  

[Christian Holland]

As my latest comment isn't really related to this ticket, i'll close this one, and have opened another:

https://devzone.nordicsemi.com/f/nordic-q-a/66002/zephyr-ncs---gpio_pin_interrupt_configure-causes-15ua-increase-in-consumption

Thanks for your help