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. 

[Rob Philip]

Also, FWIW, I tried your second code snippet:

int main(void)
{
     ble_stack_init();

 
     while (true)
    {
       __WFI();
    }
}

And my power consumption went from 0.84mA to 0.90mA.

And now another question. I was given this code using the 10.0.0 SDK and in the spirit of not changing too many things at one have continued using it. It seems to work fine for what I need to do (advertise, connect, send a few bytes back and forth) but I'm happy to change to 12.3.0 if there is a good reason. Better BLE handling, errata handled, etc.

I know it's not going to help my power issue, but it may help my application.

Thoughts?  

[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.

[Einar Thorsrud]

You are right that moving to a later SDK will not help with your power consumption. In general, there are bug fixes in all new SDK releases and errata fixes in most, but it may not be relevant for your project depending on what you are doing. In general, I always recommend customers to start developing with the latest SDK, but that doesn't mean that it necessarily makes sense to migrate an older project to a new SDK. It all depends, really.

[Rob Philip]

That's what I would have guessed as well. If I have time I may migrate to 12.3.0 in any case, so that any future issues will not have the possibility of being related to an old SDK. 

And now another question.

Is it possible, programmatically, to determine if the processor is in debug mode, and (even better) turn off debug mode if it is? I don't care if I have to set a register and restart the processor. 

My engineer says that the 1K pulldown is there, but it would be good to confirm that the processor is indeed not in debug mode. Especially since he is convinced that nothing else on the board should be causing the power draw.