nRF Connect SDK v1.8.0 + nrf_pwr_mgmt_run

[embeddedER]

Hi Team,

We are working with nRF52832 and nRF Connect SDK v1.8.0. Our application needs to sleep (power save mode) for 5 minutes and every 5 minutes it should wake-up and perform some task (including BLE Advertisement).

We believe this can be achieved using "nrf_pwr_mgmt_run", however, it seems document around this is very slick, specially for nRF Connect SDK v1.8.0. There is no example of how to use it in NRF Connect SDK with Zephyr.

So, our questions are:

1. How to put system to sleep using nRF connect SDK?

2. Is there any example that can be referred to implement BLE Sleep Mode with wake-up using timer in NRF Connect SDK?

Thanks!

[embeddedER]

Hi Einar,

Finally we got a chance to measure the power consumption for nrf52832.

We are trying to baseline the deep sleep power consumption of nrf52832 using nrf52-DK.

Setup:

• nrf52-DK (2.0.0) modified for Power Measurement (Cut PCB Track of SB9 and soldered SB12), supplied using external supply
• DAQ970A used as Ampere meter and connected to nrf52-DK on P22

Code: Used zephyr\samples\basic\blinky as a base and modified following things:

• In prj.conf added following:
  CONFIG_LOG=n
  CONFIG_SERIAL=n
  CONFIG_PM=y
  CONFIG_PM_DEVICE=y
• In main() included following header files and modified delay for blink to 10 SB12
  #include <pm/pm.h>
  #include <device.h>
• Added overlay file (nrf52dk_nrf52832.overlay) and disabled all unused peripherals.

Code zip for reference: 28501.blinky.zip

Results:

Baseline current reading is 0.7uA and then every 50 milli seconds there is a spike of 11 uA as showing in the image below.

There is a spike every 10 seconds, which is understandable since we have 10 seconds delay in main while loop.

Also checked that system is going into idle state using Ozone.

Can you please help with following queries?
- what might be causing those 11uA spikes every 50 mS?
- Is there any verified Firmware which can just blink an LED for couple of seconds and then puts system into deep sleep? (we should expect the current consumption of 1.9uA as per the datasheet)

Thanks!

[Einar Thorsrud]

Hi,

embeddedER said:

- what might be causing those 11uA spikes every 50 mS?

The spikes are caused by the LDO being in refresh mode. See this post.

embeddedER said:

- Is there any verified Firmware which can just blink an LED for couple of seconds and then puts system into deep sleep? (we should expect the current consumption of 1.9uA as per the datasheet)

About 1.9uA (though with significant chip-to-chip variation) is the expected sleep current for most sample projects that use a continuously running RTC (like any Bluetooth sample) when logging is disabled. I would expect you get that order with your application as well if you calculate the average including the spikes.