ble_app_uart example - how to get the lowest current comsumption NRF52832

[BartoszT]

Hello, I'm working with an example of ble_app_uart with SofDev132. I have modified the code a bit but I still use the nrf_pwr_mgmt_run function. The power consumption is 2.18mA for disabled BLE broadcasting and I do not turn on broadcasting for power consumption tests (tested on hardware and nRF52 DevKit) I need to have RTC turned on so I can not use low-power system-off. How to minimize power consumption using nrf_pwr_mgmt_run function to get more or less 10uA of power consumption? (For low-power system-off the current consumption is 2.5uA so the hardware is ok). 

int main(void)
{
    bool erase_bonds;

    // Initialize.
    uart_init();
    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    rtc2_init(0xFFF);//prescaler 12bit, max value 0xFFF
    rtc2_start();
    flash_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();


    // Start execution.
    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    // Enter main loop.
     
    for (;;)
    {

          if(state==START_ADV))
        { 
            state= ADV_IS_RUNNING;
                advertising_start();
        }
  
        idle_state_handle();


    }
}

[hmolesworth]

Try adding this at the start of main:

   // DC-DC power supply enable, saves about 100mA at 2.7 volts over using internal LDO regulator
   nrf_power_dcdcen_set(true);

Try closing the UART (before sleep) in particular; it can always be started again when needed while awake:

   // Terminate UART transfers serial port - saved about 1mA
   app_uart_close();

[BartoszT]

Thanks very much it works, It got 4uA current consumption.

[BartoszT]

Do you know if there is additional way to optimize the SoftDevice power consumption beside nrf_pwr_mgmt_run() ?
 

[Simonr]

None that aren't stated in the link I provided earlier.

Best regards,

Simon

[hmolesworth]

Not really, although Nordic engineers might have some suggestions. Trace that function so you can see what it does, but I'm not sure there are any improvements other than tuning transmission and reception settings - ie. send more data in fewer bursts, for example, or use 2MHz instead of 1MHz, the usual BLE stuff.

You will get further optimising your own code; the SDK code is great for getting started, but not power efficient in terms of layers for SPI, I2C, Uart and so on; talk to registers instead of using multiple layers of functions; reduce interrupts by using PPI; turn off unused RAM in sleep.

   // Set RAM power modes in system off
   //
   //  RAM0 Section 0 0x2000 0000 - 0x2000 0FFF
   //       Section 1 0x2000 1000 - 0x2000 1FFF
   //  RAM1 Section 0 0x2000 2000 - 0x2000 2FFF
   //       Section 1 0x2000 3000 - 0x2000 3FFF
   //  RAM2 Section 0 0x2000 4000 - 0x2000 4FFF
   //       Section 1 0x2000 5000 - 0x2000 5FFF
   //  RAM3 Section 0 0x2000 6000 - 0x2000 6FFF
   //       Section 1 0x2000 7000 - 0x2000 7FFF
   //  RAM4 Section 0 0x2000 8000 - 0x2000 8FFF
   //       Section 1 0x2000 9000 - 0x2000 9FFF
   //  RAM5 Section 0 0x2000 A000 - 0x2000 AFFF
   //       Section 1 0x2000 B000 - 0x2000 BFFF
   //  RAM6 Section 0 0x2000 C000 - 0x2000 CFFF
   //       Section 1 0x2000 D000 - 0x2000 DFFF
   //  RAM7 Section 0 0x2000 E000 - 0x2000 EFFF
   //       Section 1 0x2000 F000 - 0x2000 FFFF
   NRF_POWER->RAM[7].POWERSET = (POWER_RAM_POWER_S0POWER_On     << POWER_RAM_POWER_S0POWER_Pos)      |
                                (POWER_RAM_POWER_S1POWER_On     << POWER_RAM_POWER_S1POWER_Pos)      |
                                (POWER_RAM_POWER_S0RETENTION_On << POWER_RAM_POWER_S0RETENTION_Pos)  |
                                (POWER_RAM_POWER_S1RETENTION_On << POWER_RAM_POWER_S1RETENTION_Pos);

There are some Nordic blogs about power optimisation, worth reading those though I don't have the links to hand.

If any signals float in sleep (or ever), disconnect those inputs to avoid phantom power consumption from feedthrough when the pin happens to float to the vanishingly small transition point where feedthrough occurs. If any external devices are powered from a port pin ensure all other i/o pins to that part are driven low or allowed to float when that device is powered down to avoid any potential reverse phantom power or backdrive issues.

4uA is not bad; check the leakage spec (mostly capacitors) and Iq on any devices on your board if you want to go lower. How much capacitance is accross the CR2032 (if you are using one)? I recommend 150uF to reduce losses over the battery lifetime.

Have a look at some of Jack Ganssle's articles, Jack has some good suggestions. email him, tell him I recommended you - he's a good chap who knows stuff.