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

[DW]

Hi,

My stack is

• s112
• SDK 15.3
• Segger
• nrfConnect
• nrf52832 DK
• Power profiler kit connected via USB to my MAC to get the traces to run.
• CR2032 batter removed
• SB9 solder jumper cut

I have my code effectively running on the uP as I need it, and I now have  the Power Profiling Kit so I can start to power optimise.  I have modified the ble_app_proximity example but when running it, it sits at a baseline of 2.7mA while in advertising mode and when connected to the central.

To analyse my first step was to flash the board with the unmodified ble_app_proximity to see if it was my code.

The unmodified code gives a trace below which also sits at 2.7mA average also

The mystery deepens however. In my code I have PIN 16 wired to ground and when it goes high (switch open) I send the chip into sd_power_system_off();

This works elegantly and I can see that we drop to 6uA or thereabouts when the switch os opened. Just as it should.

So it leads me to wonder why the 2.3mA is the baseline when advertising and when connected. So I am a little stumped and perhaps I am missing something simple but the 2.3mA is going to drain my CR2032 very fast so any tips on how I get the uP to sleep between advertisements? Also I am looking to power optimise by extending the advertising interval and raising the slave latency. But the 2.7mA baseline dwarfs any advantages chosen here. 

I've found this thread leading me to think it is my technique which is highly likely, but there is no answer on the thread. It just ends with no resolution. I've power cycled the board multiple times after flashing it.

I've found this thread leading me to understand (incorrectly?)  that the softdevice prevents the low power state from ever firing?

Looking at the code it appears that nrf_pwr_mgmt_run() never goes to sleep as the "else" statement is never run, as I am running a softdevice. 

void nrf_pwr_mgmt_run(void)
{
    PWR_MGMT_FPU_SLEEP_PREPARE();
    PWR_MGMT_SLEEP_LOCK_ACQUIRE();
    PWR_MGMT_CPU_USAGE_MONITOR_SECTION_ENTER();
    PWR_MGMT_DEBUG_PIN_SET();

    // Wait for an event.
#ifdef SOFTDEVICE_PRESENT
    if (nrf_sdh_is_enabled())
    {
        ret_code_t ret_code = sd_app_evt_wait();
        ASSERT((ret_code == NRF_SUCCESS) || (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED));
        UNUSED_VARIABLE(ret_code);
    }
    else
#endif // SOFTDEVICE_PRESENT
    {
        // Wait for an event.
        NRF_LOG_INFO("Got to here");
        NRF_LOG_FINAL_FLUSH();
        __WFE();
        // Clear the internal event register.
        __SEV();
        __WFE();
    }

    PWR_MGMT_DEBUG_PIN_CLEAR();
    PWR_MGMT_CPU_USAGE_MONITOR_SECTION_EXIT();
    PWR_MGMT_SLEEP_LOCK_RELEASE();
}

My setup. I connect the USB, fire teh mrfConnect power profiler on the laptop, power cycle the DK board. The yellow wire is my "switch" tying pin 16 to ground. On open the board goes to sleep effectively

Any help appreciated.

Best,

DW

[cbd]

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.

[DW]

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?

[Jørgen Holmefjord]

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

[DW]

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,

DW

[Jørgen Holmefjord]

Try to also disable the logger:

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