Can't get BLE device to sleep

[prsboy]

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.

[Edvin]

Hello,

3A sounds like a lot. I don't think you are able to even draw that much through the nRF. Not 1.48A either. We should be talking about perhaps 20mA, or something around those numbers.

Have you had your PCB design through a design review with Nordic? If not, perhaps you should create a ticket for that (so that it will be assigned to one of our HW engineers).

Other than that, I can't say that I can see anything wrong with your application. Regarding the power, I see that you are using idle_state_handle() in your main-loop, so the device should enter sleep.

I don't know what kind of crypto things you are doing, but to rule it out. Does it still draw as much power if you remove that as well? (just to make sure that the CPU isn't running all the time). 

How do you measure the current consumption? Are you using the Power Profiler Kit 2? Or some other device?

Best regards,

Edvin

[prsboy]

Eugh. Apologies, of course I mean mA not A. so ~3mA and 1.4mA. I'll edit my original answer.

I'm using both a custom PCBA and also an NRF52DK (by following the document to cut the connection then measure over the power consumption pins). I will take another reading using the DK but the power wasn't too different to what I was seeing on my custom PCBA (with no sleep happening).

In terms of the crypto, it's not that, I've checked this also. It's definitely the BLE that's causing the device not to go into sleep mode.

[prsboy]

Indeed, very strange.

Edvin said:

Do you happen to have a PPK2? If so, can you please capture some graphs from running on SYNTH, and from running the RC_OSCILLATOR? A multimeter doesn't really give a clear picture of what's going on.

Will a PPK1 do? I can get ahold of one of those in a few days.

Edvin said:

Have you tried to capture a sniffer trace of the advertisements? You can do so using the nRF Sniffer for Bluetooth LE. If possible, can you upload one trace usnig SYNTH and one using the RC_OSCILLATOR?

I will get those sniffer traces uploaded for both SYNTH and RC. 

Edvin said:

If you have not already, I suggest that you also create a new ticket where you upload your schematics and PCB layout and ask for a layout review. I am not sure what it would be, but perhaps one of our HW engineers can spot something that I have not thought of. 

How do I request a specific hardware review?

[Edvin]

prsboy said:

Will a PPK1 do? I can get ahold of one of those in a few days.

Yes. That works too. The PPK2 is a bit easier to use, but the PPK 1 will still give accurate readings, and perhaps show some patterns that can reveal something.

prsboy said:

How do I request a specific hardware review?

Just create a ticket here on DevZone (but make it private, unless you want your design to be out in the public), and add your PCB layout files and your schematics. If you didn't design the HW, then talk to the people who did, and they probably know what files we are talking about. And if something is missing, the HW engineer from our side that is assigned to the ticket will know what additional files to request. 

However, before you do this. Did you test this on one device, or do you have several custom boards? It would be interesting to know whether this behavior is only present on one nRF Chip, or several. 

BR,
Edvin

[prsboy]

hello again Edvin !

After a few attempts at trying to get the PPK1 to work, I managed to take some readings. This is with the previously mentioned configuration:

#define CLOCK_CONFIG_LF_SRC 0
#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 1
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#define NRF_SDH_CLOCK_LF_ACCURACY 9

with 10 seconds advertising, then 120 seconds sleep. This is the graph for one sleep/wake cycle

here is 1 seconds worth of data for the awake period

and here is 1 second for the sleep period

this all seems very high to me, so perhaps i've not setup the device correctly. here's how i have it setup:

1. I have plugged the PPK1 into the DK.

2. I have plugged in the computer to the DK. 

3. I have used the EXTERNAL OUT pins on the PPK1 to provide power to my custom PCBA

does that make sense? if not, I can take a photo.

[Edvin]

Is this how you connected your custom HW?
https://infocenter.nordicsemi.com/topic/ug_ppk/UG/ppk/PPK_user_guide_PPK_on_customHW_with_nRF5xDK.html?cp=11_10_5_4

If so, which one of the figures did you follow? And did you make sure that all the switches are set in the position that are noted in the figures?

I agree, your numbers seems a bit too high. 

BR,

Edvin

[prsboy]

Yep, this is exactly how i've got it setup, I re-ran the test again today and got the same results.

i'm going to start removing stuff from the program and see if i can identify what's causing this "active"state to be 80mA.

The good news is:

After going back to the hardware it seemed like the original problem was around the antenna. It seems like the incorrect antenna setup was causing the device to need more power (i'm guessing) for me to be able to receive a signal (perhaps why SYNTH worked fine best?).

I have had a new set of prototype devices manufactured and I have set the device up as recommended 

#define 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

and the device now is advertising perfectly clearly:

and now with the correct/recommended LF clock settings, we can see the sleep cycle is an actual sleep cycle:

so I guess the only remaining thing is to work out the high power consumption when in bluetooth advertisement