Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

Jørgen Holmefjord — Mon, 12 Aug 2019 19:17:54 GMT

Glad to hear! We prefer if you post your questions as separate threads on DevZone. If you would like to avoid posting the question in public, there is a private option when you create the ticket. If you want to ask something specific to me, you can mention that in the case, but we normally distribute the tickets internally based on who is most capable to answer the specific topic!

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

DW — Mon, 12 Aug 2019 16:48:24 GMT

Thank you Jørgen. Everything has fallen into place. I should be able to reduce that current draw on PIN 16 as per the discussion board here

Testing tonight!

Jørgen - Could I reach out to you with another question, privately?

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

Jørgen Holmefjord — Mon, 12 Aug 2019 13:36:01 GMT

The size of the current sounds like it could correspond to a current flowing through your pullup resistor (~13kOhm, which would give ~230 uA @ 3.0V).

By default, the DK has BUTTON4 connected to P0.16. Have you connected anything else to the pin? The switch on the DK is active low.

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

DW — Sat, 10 Aug 2019 02:27:57 GMT

Once again thank you Jørgen,

I have implemented the

    NRF_POWER->DCDCEN = 1;

to select the lower power use of DCDC and understand that if it drops below 2.1v I should switch it off. I can see that the individual advertising spikes are lower, which is great. However I was still at 230uA. So for the past evening I thought I must, by process of elimination, work out what is doing it. So I started completely fresh, with the ble_app_template app and added my services one by one, testing the power profile as each service was added. The lls and bas services were added and power behaved beautifully. It is when I added my GPIOTE event, that the current runs high.

The specific lines of code that do it are in the gpio initialisation done in switch_int()

static void switch_init(void)
{
    ret_code_t err_code;

	//Initialize gpiote module
    //NRF_LOG_INFO("Initialize gpiote module");
    if(!nrf_drv_gpiote_is_init())
        {
        err_code = nrf_drv_gpiote_init();
        APP_ERROR_CHECK(err_code);  
        }    
    //Configure sense input pin
    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);                                //Configure to generate interrupt and go to system_off on pin signal high. "false" means that gpiote will use the PORT event, which is low power, i.e. does not add any noticable current consumption (<<1uA). Setting this to "true" will make the gpiote module use GPIOTE->IN events which add ~8uA for nRF52 and ~1mA for nRF51.
    in_config.pull = NRF_GPIO_PIN_PULLUP;                                                                       //Configure pullup for input pin to prevent it from floating. Pin is pulled down when button is pressed on nRF5x-DK boards, see figure two in http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52/dita/nrf52/development/dev_kit_v1.1.0/hw_btns_leds.html?cp=2_0_0_1_4		
    err_code = nrf_drv_gpiote_in_init(SWITCH_PIN, &in_config, in_pin_debounce_handler);  				//Initialize the pin with interrupt handler in_pin_handler

    //NRF_LOG_INFO("Intiate the PIN to detect switch opening: Error code on gpiote_in_init is %d..", err_code);
    //APP_ERROR_CHECK(err_code);                                                          			//Check potential error
    //nrf_drv_gpiote_in_event_enable(SWITCH_PIN, true);                                                           //Enable event and interrupt for the wakeup pin
}

Note: I have not enabled the switch detection in the final line, as it is specifically the nrf_drv_gpiote_in_init command, configured as I have configured it above, that sends the current usage up.

I understood that by setting GPIOTE_CONFIG_IN_SENSE_LOTOHI(false) to "false" I was using a low power PORT event.

I call this gpio initialisation from main

/**@brief Function for application main entry.
 */
int main(void)
{
    bool erase_bonds;

    // Initialize.
    
    NRF_POWER->DCDCEN = 1;
    log_init();
    timers_init();
    //buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    advertising_init();
    services_init();
    conn_params_init();
    peer_manager_init();

    // Start execution.
    NRF_LOG_INFO("Template example started.");
    application_timers_start();
    tx_power_set();
    advertising_start(erase_bonds);
    switch_init();

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

Looking further tonight and analysing the Power Profiler Kit, by running switch_init() the 230uA level is I think caused by something triggering every 25ms resulting in the jagged baseline?

Have also used the online power profiler kindly provided by Nordic

using the variables of

voltage : 3
DCDC regulator now enabled

LF Clock on the development board is External crystal as set in the sdk_config.h

```
#define NRF_SDH_CLOCK_LF_SRC 1
```
```
#define NRFX_CLOCK_CONFIG_LF_SRC 1
```
```
#define CLOCK_CONFIG_LF_SRC 1
```

Advertising interval is 2.022 seconds

#define APP_ADV_INTERVAL                3236                                    /**< The advertising interval 2.022 seconds. */

TX Payload I have yet to calculate so I've maxed it out to 31

The anticipated current should be 7.8uA. It's definitely this 25ms tick that my code has which is creating the unwanted 230uA. As I added the lls and bas the baseline was smooth

Any advice gratefully received.

Best DW

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

Jørgen Holmefjord — Thu, 08 Aug 2019 09:01:54 GMT

If it is not initialized in the code, those peripherals should not cause increased current consumption from being enabled in the sdk_config.h file.

I would recommend that you check if your average current is in line with the expected currents from the Online Power Profiler.

Enabling the DCDC converter would also reduce the average current quite a lot.

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

DW — Thu, 08 Aug 2019 06:44:56 GMT

Once again thank you. The power profile kit is now averaging 230uA. Can I disable other things I think I'm just not using scuh as the the UART, CRYPTO, CLOCK peripheral driver, Peripheral Resource Sharing module, FPRINTF module?

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

Jørgen Holmefjord — Wed, 07 Aug 2019 13:37:34 GMT

Try to also disable the logger:

// <e> NRF_LOG_ENABLED - nrf_log - Logger
//==========================================================
#ifndef NRF_LOG_ENABLED
#define NRF_LOG_ENABLED 0
#endif

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

DW — Wed, 07 Aug 2019 13:34:08 GMT

Thank you Jørgen,

This is a huge improvement to circa 750uA (ish). The advertising, connecting and connected trace is below.

Any other suggestions to further reduce the current draw?

Best,

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

Jørgen Holmefjord — Wed, 07 Aug 2019 09:19:50 GMT

Hi,

I believe this is caused by the SAADC that is used for battery voltage measurement in the example.

Please try enabling low power mode by setting the following in your sdk_config.h file:

// <q> SAADC_CONFIG_LP_MODE  - Enabling low power mode
 

#ifndef SAADC_CONFIG_LP_MODE
#define SAADC_CONFIG_LP_MODE 1
#endif

Best regards,
Jørgen

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

DW — Tue, 06 Aug 2019 22:07:30 GMT

Hi cbd,

Thanks for the super fast response.

I have updated the following setting and re-run

#define APP_ADV_INTERVAL 3236 /**< The advertising interval 2.022 seconds. */

So advertising seems to idle the CPU at 2.5mA

It is almost as though the sd_app_evt_wait(); never sends the CPU to sleep and prefers to run the CPU at 2.5mA between advertising transmissions?

i.e.
__WFE();
// Clear the internal event register.
__SEV();
__WFE();

is never called in the SDK code?

RE: Proximity Example - Power profiling sits at baseline 2.7mA and does not sleep between advertisements

cbd — Tue, 06 Aug 2019 12:26:02 GMT

Your advertising rate seems pretty fast. This could be the issue.

To save power you should extend your advertising period out. Try setting setting it to something like 350 - 500ms and you'll probably see the average consumption drop.

When advertising, not only are you drawing power to transmit, but also for the period immediately after where your are listening for a response requesting a connection. This differs to a beacon which doesn't expect a response. This is why advertising is typically limited to 30 seconds or less.

If the advertising rate is fast enough the soft device will never put the chip into a low power mode as the transmit and receive periods will merge.