Trying to reduce power consumption

[Rob Philip]

I have a small project on a custom board using an nRF51824 processor. 

The code basically initializes the BLE stack timer and GPIO and then falls into a loop

while (true) sd_app_evt_wait(); 

The timer (using RTC) fires every 5 seconds to kick the watchdog and check for a connect timeout condition (15 minutes). 

When I connect I'm responding to one of a half dozen commands.

While advertising for a connection I see the board draw 0.92 - 0.97 milliamps. When connected I draw 1.01 - 1.10 milliamps. 

Whether connected or not, 99.99% of the time my application is not doing anything other than sleeping. 

What I'd like to do is reduce the power draw when advertising and connected as much as possible. 

My advertising interval is 250ms.

Thoughts where I should look? 

[Einar Thorsrud]

Hi,

The device should not consume this much with the code you describe. You may have the chip in debug mode, as the nRF51 consumes about 1 mA when debug mode is enabled. Do you have a debugger connected to the device when you do current measurements? If so, try disconnecting it before you do current measurements. Does current consumption come down when you do?

The nRF51 series current consumption guide has a good overview of what you should do to reduce current consumption of your nRF51 device.

 

[Rob Philip]

The link you provided has links to "system on mode example" and "system off mode example". But they are dead links. Can you point me at a good link for these. Or the example in the 10.0.0.0 SDK. 

Thanks.

[Rob Philip]

Also, there are a bunch of references to "https://devzone.nordicsemi.com/index.php/why-does-my-nrf51822-consume-1-ma-in-sleep" but that link is dead too... Do you have a current link for that? 

[Einar Thorsrud]

It is probably this question.

[Einar Thorsrud]

Hi,

You can find the examples from the nRF51 series current consumption guide here. The SDK has evolved significantly (SDK 12.3 is the latest release for nRF51), so they may not work out of the box unless you use SDK 11 for the test. You can also use the Power Profiling Application example from to test current consumption in most scenarios (BLE advertising with system ON sleep mode between BLE events, BLE connection with system ON sleep mode between events and system OFF).

You can make very simple firmware examples to test the basic low power modes. This simple main function will go immediately to system OFF low power mode. If you see a current consumption larger than a few micro amps, this comes from either 1) other components on your BPS, or 2) the nRF51 is in debug mode.

int main(void)
{
    // Enter system off low power mode mode.
    NRF_POWER->SYSTEMOFF = 1;

    while (true)
    {
        // Should never arrive here
    }
}

You can make a similar system ON example by taking a BLE example, and only initialize the SoftDevice before you go to sleep (see code snippet below). Initializing the SoftDevice will start the LFCLK and RTC0, which is the only resources you need enabled during sleep for a simple BLE application. It would look something like this (SDK 12.3). The nRF will stay in system ON low power mode indefinitely if a 32 kHz crystal is used. If not, it will wake up regularly to calibrate the 32 kHz RC oscillator (depending on the configuration when you initialized the SoftDevice).

int main(void)
{
    // Call ble_stack_init implemented in the main.c file of a BLE peripheral examples
    ble_stack_init();
    
    // Enter main loop.
    for (;;)
    {
        power_manage(); // System ON low power mode.
    }
}

[Rob Philip]

Thanks.

I implemented the following:

int main(void)
{
   NRF_POWER->SYSTEMOFF = 1;

   while (true)
   {
      __WFI();
   }
}

And I'm pulling 0.84 mA

The hardware engineer checked and the 1K resistor is on the SWDCLK line. There is no debugger attached, as I program the code and then move the device from the debugger socket. 

I will let him know definitively that there are other things on the board that are drawing power. 

Thanks for your help. I'm going to leave this open until the hardware engineer either changes the hardware or tells me that he won't be doing so. 

[Einar Thorsrud]

I would say that this strongly indicate that there is a hardware issue. You (or rather the HW guy) can verify by isolating either the VDD or VSS pins from the PCB, and connecting them via an ampere meter (or resistor you measure voltage drop over). This way you can compare the current consumption of the whole PCB with the current consumption of only the nRF.