Current consumption ble

[lydie]

Hi,

I'm using nrf52832 with s132, so I don't find any information about the current consumed by the device when I'm connected by Bluetooth. I use the driver st7735 and an LCD screen. When my phone is not connected by Bluetooth and my device sleep, the current is 0.43mA. When my phone is not connected, and the LCD screen is ON, the current is around 3.4mA. Until then, everything is normal. But when I'm connected and my device is sleeping, the current is 1.5mA, and if the screen is ON the current is 0.7mA. So I don't understand why the current is increased when I'm connected and when my device is sleeping? And why the current decrease when the screen displays something. On online power profiler, the power consumes when there is a connection but the device is asleep is not indicated, so I don't know if it is normal or not. 

Thanks,

Lydie

[bjorn-spockeli]

Hi Lydie, 

which S132 version and SDK version are you using? 

All the BLE examples in our nRF5 SDK will go to sleep when the CPU is idling, i.e. in between connection events and advertisment events. Our SoftDevice is 100% event driven so, whenever the nRF is in the main for() loop it will call idle_state_handle(), which in turn calls nrf_pwr_mgmt_run(), which in turn calls sd_app_evt_wait() or __WFE(). These functions will make the CPU sleep until there is an interrupt or event that wakes up the chip, i.e. a timer expiring or a BLE event like advertisment or a connection event. So as long as you're calling idle_state_handle() in the main for loop, the nRF should go to sleep in between connection events. 

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.
        __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();
}

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


/**@brief Function for application main entry.
 */
int main(void)
{
    // Initialize.
    log_init();
    leds_init();
    timers_init();
    buttons_init();
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();

    // Start execution.
    NRF_LOG_INFO("Blinky example started.");
    advertising_start();

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

If its not going to sleep, then there must be a pending event/interrupt that keeps the CPU from sleeping, i.e. causes sd_app_evt_wait() or __WFE() to return immediately. 

On online power profiler, the power consumes when there is a connection but the device is asleep is not indicated, so I don't know if it is normal or not. 

 The online power profiler will calculate the average current consumption with the assumption that the CPU goes to sleep inbetween connection and/or advertisment events. 

Best regards

Bjørn

[lydie]

Hi,

I'm using sdk15.3. Ok I understand, so to decrease the current, I have to find which event or advertisement prevent the CPU from sleeping. But I haven't found any events. I tried with cts example, but the current neved decreases when I'm connected.

Thanks for your reply.

Lydie

[lydie]

Fluke 87 Handheld Digital Multimeter, 10A ac 1000V ac 10A dc 1000V dc. But as I said, the mean of measuring the current is not the problem because I can see the current variation when it goes to sleep (system ON) and when it is not connected.

[bjorn-spockeli]

OK, the resolution of the Fluke 87 V is 0,01 µA. The Fluke meter is set to uA when you're measuring the System On current right? I just want to make sure that the measurement HW is accurate enough, otherwise the current measurements can be way off, showing higher average current consumption because either the resolution or sampling rate isnt high enough.  We see a lot of measurements done with HW that is not accurate enough and the average current consumption numbers will then be all over the place. 

lydie said:

But as I said, the mean of measuring the current is not the problem because I can see the current variation when it goes to sleep (system ON) and when it is not connected.

 Are you initializing any peripherals when you get the connected event? Are you advertising when you're not connected? If so which advertisment interval? If you're expecting the nRF to sleep in between the advertising events, then you can toggle a GPIO after calling idle_state_handle(). If the nRF is only waking up from the advertisment events, then you should see the GPIO toggle at the same interval. 

If it toggles at a higher interval, then I would start putting log statements or toggeling GPIOs in event handlers to figure which event thats waking up the nRF. 

Best regards

Bjørn

[lydie]

No in mA, otherwise it doesn't work. When I'm connected, I do that:

case BLE_GAP_EVT_CONNECTED: {
    NRF_LOG_INFO("Connected.");
    printf("Connected.\n");
    err_code = bsp_indication_set(BSP_INDICATE_USER_STATE_OFF);
    APP_ERROR_CHECK(err_code);
    // Assign connection handle to the Queued Write module.
    m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
    err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
    APP_ERROR_CHECK(err_code);
     
    memset(&m_ble_db_discovery,0,sizeof(m_ble_db_discovery));
    // Discover peer's services.
    err_code = ble_db_discovery_start(&m_ble_db_discovery,
        p_ble_evt->evt.gap_evt.conn_handle);
    APP_ERROR_CHECK(err_code);

    // Used to track connections state
    isConnected = true;

   // sd_ble_gap_rssi_start(p_ble_evt->evt.gap_evt.conn_handle, 3, 0);

When I'm not connected, I'm advertising because I call advertising_start() in the main function. The advertising interval is :

#define APP_ADV_INTERVAL 40

So it is less than 100ms.

I print something in all event handler function (which represents all services I use)
like on_hts_evt(), on_cts_c_evt, fds_evt_handler, pm_evt_handler, saadc_event_handler, db_disc_handler, gatt_evt_handler, on_adv_evt, nus_data_handler, on_ias_evt, on_lls_evt, on_ias_c_evt, ble_evt_handler, bsp_event_handler
No events appear in these functions. So how can I know what event is keeping my cpu from sleeping?  

[bjorn-spockeli]

OK, so the nRF device is acting as the BLE central and the phone is the BLE peripheral?

lydie said:

I print something in all event handler function (which represents all services I use)
like on_hts_evt(), on_cts_c_evt, fds_evt_handler, pm_evt_handler, saadc_event_handler, db_disc_handler, gatt_evt_handler, on_adv_evt, nus_data_handler, on_ias_evt, on_lls_evt, on_ias_c_evt, ble_evt_handler, bsp_event_handler
No events appear in these functions. So how can I know what event is keeping my cpu from sleeping?  

 Ok, then we need to check if idle_state_handle() is returning immediatly or not. Do you have the possiblity to  toggle a GPIO after calling idle_state_handle() and then monitoring the GPIO using a logic analyzer or oscilloscope?

Note that having logging enabled will increase the current consumption so it should be disabled when measuring the current consumption. Thats why I usually toggle a GPIO instead of printing log statements.

Best regards

Bjørn

[lydie]

Yes that’s right. When idle_state_handle() is called, an event arrives and immediately wakes up the device, so the current has not time to decrease. I print something in the idle_state_handle() function, and it is print a lot of time like it was trying to sleep but it couldn’t. 

Yes I disabled Log. 

[bjorn-spockeli]

Ok, so when you print you're not using the nRF_LOG API? Or do you mean that you tested bot with log enabled and with logging disabled?

If none of the event handlers below are called then I would check the peripherals that you are using in your application, i.e. see if any of the EVENTS_xxxx registers are set to 1 prior to calling sd_app_evt_wait().

Best regards

Bjørn

[lydie]

No I’m not using Log API. What do you mean by EVENTS_xxxx

[bjorn-spockeli]

Ok, so you are using the UART to print log statements? By EVENTS_xxxx I mean the EVENTS registers for each of the peripherals, e.g. the UART event registers listed here: UART Registers

EVENTS_CTS	0x100	CTS is activated (set low). Clear To Send.
EVENTS_NCTS	0x104	CTS is deactivated (set high). Not Clear To Send.
EVENTS_RXDRDY	0x108	Data received in RXD
EVENTS_TXDRDY	0x11C	Data sent from TXD
EVENTS_ERROR	0x124	Error detected
EVENTS_RXTO	0x144	Receiver timeout

If any of these registers are set to 1, i.e. there is a pending event, then sd_app_evt_wait will return immediatly.

Best regards

Bjørn

[lydie]

Yes! Ok, and how can I know if any of EVENTS_xxxx are set to 1?

[bjorn-spockeli]

Well, you could print the values with the UART interface or monitor the registers of the peripherals in debug session.