Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Can't get BLE device to sleep

I have a custom PCBA with which has the flow of:

- Boot

- Advertise some temperature data read from TWI with a 5 second timeout using `ble_adv_fast_timeout`.

- I then set a timer to wake the `app_timer_start(m_awake_timer_id, APP_TIMER_TICKS(SLEEP_IN_MS), NULL);`

And I expect the device to go into sleep whilst its BLE is not advertising. Here's my main.c file:

#include "app_timer.h"
#include "nrf_pwr_mgmt.h"
#include "nrf_crypto_init.h"
#include "nrfx_clock.h"

#include "SEGGER_RTT.h"
#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"
#include "nrf_delay.h"

#include "customble.h"
#include "peripheral.h"
#include "encryption.h"

void timers_init(void)
{
  ret_code_t err_code = app_timer_init();
  APP_ERROR_CHECK(err_code);
}

static void idle_state_handle(void)
{
  if (NRF_LOG_PROCESS() == false)
  {
    nrf_pwr_mgmt_run();
  }
}

/**@brief Function for initializing power management.
 */
void power_management_init(void)
{
  ret_code_t err_code;
  err_code = nrf_pwr_mgmt_init();
  APP_ERROR_CHECK(err_code);
}

int main(void)
{
  NRF_LOG_INIT(NULL);
  NRF_LOG_DEFAULT_BACKENDS_INIT();

  ret_code_t reta = nrf_crypto_init();
  APP_ERROR_CHECK(reta);

  timers_init();
  ble_timers_init();
  ble_stack_init();

  power_management_init();

  gap_params_init();
  advertising_init();

  advertising_start();

  for (;;)
  {
    idle_state_handle();
  }
}

and here's the relevant sections of the customble.c code

void awake_timer_handler()
{
  NRF_LOG_INFO("Awake and start advertising");

  update_advertising_data_while_advertising();
  advertising_start();
}

void sleep_timer_handler()
{
  NRF_LOG_INFO("asleep");

  sd_ble_gap_adv_stop(m_advertising.adv_handle); // i've tried with and without this

  // Proceed with setting the device to low power mode
  app_timer_start(m_awake_timer_id, APP_TIMER_TICKS(SLEEP_IN_MS), NULL); // 60 seconds
}

void on_adv_evt(ble_adv_evt_t ble_adv_evt)
{
  NRF_LOG_INFO("BLE EVENT");
  switch (ble_adv_evt)
  {
  case BLE_ADV_EVT_IDLE:
    NRF_LOG_INFO("Advertising event: Idle");
    sleep_timer_handler();
    break;
  }
}

I have measured the amps on the device and during advertising it jumps to about 3mA and when it's not advertising (when I thought it would sleep) it's using ~1.48mA. What exactly am I doing wrong here?

I have commented lots of things out, and it's not the TWI causing the issue, it's definitely the BLE. When I comment out starting BLE, I get ~400uA constant.

Parents
  • Hi

    I'm taking over this case until Edvin is back now, and from reading it seems you're on a good path now. Just to confirm, the issue remaining is that you're seeing a ~400µA current draw "extra" when enabling the radio/BLE, correct? If so, that's likely the HF crystal drawing this current, as that will draw ~400µA when running, and is required to run for the radio peripheral to work, and this will be expected. Let me know if I'm misunderstanding something with your issue here.

    Best regards,

    Simon

  • Hey Simon!

    The only issue remaining is posted here and it's drawing 80mA, not 400uA. This number seems wildly high for the radio/BLE cycle.

    The sleep cycle is fine, it draws the correct/expected current.

    Nathan

  • Hi Nathan

    80mA is more than the nRF52 series devices are able to draw altogether I think, so this current consumption measurement can't be correct I'm afraid, so please double check how the Power Profiler Kit is set up to measure the current here. Usually when seeing this number from a PPK, you also see the current consumption from the connected J-Link debugger chip onboard the connected DK for some reason.

    I'd recommend using a PPK2 if you have available as it is notably easier to use and more accurate too.

    Best regards,

    Simon

  •   

    It's taken a long time, but I finally got myself hold of a PPK2 and the measurements are looking much more reasonable:

    I think I can finally mark this as solved. I think to sum up the problems faced:

    1. My setting of SYNTH for the clock LFCLK. This caused the device never to sleep.

    2. The reason I needed SYNTH was that there was a hardware issue within the PCB design effecting the antenna which caused BLE not to be detectable using anything other than a configuration that caused the device to not be able to sleep (or otherwise be undetectable).

    3. Once 2. was resolved, I could set LFCLK to RC Oscillator and use the recommended settings for the LFCLK 

    #define CLOCK_CONFIG_LF_SRC 0
    #define NRFX_CLOCK_CONFIG_LF_SRC 0
    #define NRF_SDH_CLOCK_LF_SRC 0
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
    #define NRF_SDH_CLOCK_LF_ACCURACY 1

    4. The PPK1 was giving unreliable readings for power measurement meaning that the readings were showing some clearly erroneous results. Purchasing a PPK2 to test helped show the correct power reading, which averages:

    ~4.55uA

    Thank you for your patience with this - it's been quite an puzzle on my side. Thanks for baring with me during it, I really appreciate the support, it's been top quality.

Reply
  •   

    It's taken a long time, but I finally got myself hold of a PPK2 and the measurements are looking much more reasonable:

    I think I can finally mark this as solved. I think to sum up the problems faced:

    1. My setting of SYNTH for the clock LFCLK. This caused the device never to sleep.

    2. The reason I needed SYNTH was that there was a hardware issue within the PCB design effecting the antenna which caused BLE not to be detectable using anything other than a configuration that caused the device to not be able to sleep (or otherwise be undetectable).

    3. Once 2. was resolved, I could set LFCLK to RC Oscillator and use the recommended settings for the LFCLK 

    #define CLOCK_CONFIG_LF_SRC 0
    #define NRFX_CLOCK_CONFIG_LF_SRC 0
    #define NRF_SDH_CLOCK_LF_SRC 0
    #define NRF_SDH_CLOCK_LF_RC_CTIV 16
    #define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
    #define NRF_SDH_CLOCK_LF_ACCURACY 1

    4. The PPK1 was giving unreliable readings for power measurement meaning that the readings were showing some clearly erroneous results. Purchasing a PPK2 to test helped show the correct power reading, which averages:

    ~4.55uA

    Thank you for your patience with this - it's been quite an puzzle on my side. Thanks for baring with me during it, I really appreciate the support, it's been top quality.

Children
Related