Only BLE sleep and wake-up sequence control in a nRF52832, while CPU running in normal mode

[jinvers]

Hello,

For the development of a new device I am using a custom hardware with a nRF52832 chip. I am working over the nRF5_SDK_17.1.0 using the SES IDE environment.

As a controller, the nRF52832 manages a state machine for acquiring some data from an SPI sensor and storing this data in a SPI flash. I only need to connect the device by BLE during some specific moments.

So, for increasing the autonomy of the small battery the device has, I would need that the CPU could run in normal mode while the BLE should be sleep. And wake-up the BLE in a controlled way in those specific moments. And after having transmitted the information, I should put the BLE services to sleep again.

Do you know of any example that could help me for managing this?

Thank you very much in advance.

Regards,

Joel

[Einar Thorsrud]

Hi Joel,

In practice, BLE (in some form) will be in use when scanning, advertising or being in one or more BLE connections. If you disconnect any connections, and stop advertising and scanning (if you ever to that), then BLE will not be in use, and will not contribute to the current consumption.

Exactly how to do this is application specific so I don't have any good examples, but generally it mens that if you are done with BLE, call the API's that stop it. If in a connection, call sd_ble_gap_disconnect(). And if advertising, call sd_ble_gap_adv_start(). And so on. And when you need to use BLE, start these tasks again (in the same way as you started originally, but without the configuration step). For instance, if using the advertising module, call ble_advertising_start() to start advertising.

Einar

[jinvers]

Hi Einar,

Thank you for your answer.

Is there no specific function for putting BLE in sleep mode? Does the nRF52832 put BLE in sleep mode automatically?

Best Regards,

Joel Invers

[jinvers]

Hello Einar,

At the beginning of the main() function I call the next initializations:

    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();
    printf("\r\nUART started.\r\n");
    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    advertising_start();
    ble_gap_addr_t my_addr;
    err_code = sd_ble_gap_addr_get(&my_addr);
    APP_ERROR_CHECK(err_code);
    NRF_LOG_INFO("addr %02x:%02x:%02x:%02x:%02x:%02x", my_addr.addr[0],
                                                      my_addr.addr[1],
                                                      my_addr.addr[2],
                                                      my_addr.addr[3],
                                                      my_addr.addr[4],
                                                      my_addr.addr[5]);    

In the services_init() function I initiate the NUS and the DFU services:

static void services_init(void)
{
    uint32_t           err_code;
    ble_nus_init_t     nus_init;
    nrf_ble_qwr_init_t qwr_init = {0};

    // Initialize Queued Write Module.
    qwr_init.error_handler = nrf_qwr_error_handler;

    err_code = nrf_ble_qwr_init(&m_qwr, &qwr_init);
    APP_ERROR_CHECK(err_code);

    // Initialize NUS.
    memset(&nus_init, 0, sizeof(nus_init));

    nus_init.data_handler = nus_data_handler;

    err_code = ble_nus_init(&m_nus, &nus_init);
    APP_ERROR_CHECK(err_code);

    // Initialize the DFU service
    ble_dfu_buttonless_init_t dfus_init =
    {
        .evt_handler =  ble_dfu_buttonless_evt_handler
    };
    err_code = ble_dfu_buttonless_init(&dfus_init);
    APP_ERROR_CHECK(err_code);

}

For selectively stopping all these tasks and stop all the BLE tasks (for maximum consumption reduction) what would be the best way/,method/codesequence that you would suggest to use?

For reset them again I understand i should reinitiate them according to the same code I have shared. Is this ok?

Thank you very much in advance.

Regards,

Joel

[Einar Thorsrud]

Hi Joel,

jinvers said:

For selectively stopping all these tasks and stop all the BLE tasks (for maximum consumption reduction) what would be the best way/,method/codesequence that you would suggest to use?

There is no need to uninitialize anything Bluetooth related, but you should stop advertising, scanning (if relevant) etc if needed, or reduce the advertising interval etc if needed. This may not be as important as you could think, as the Bluetooth stack itself will not significantly contribute to the current consumption except during advertising events or connection events (or in scan windows). That is highly power optimized. You can see how this works on the current consumption by playing wth the online power profiler.

jinvers said:

For reset them again I understand i should reinitiate them according to the same code I have shared. Is this ok?

Yes. For the other libraries etc. you use, it varies both on what you do and how you use it. Only NUS will not cause any issues, as that is just bluetooth. But do you also use UART? And is that always enabled? If so, the current consumption will be significant. So you should disable UART when you don't need it, and re-enable when you do. And logging you should disable for your production builds, as logging over UART will keep a UART instance the HW clock always running. 

[jinvers]

Hi Einar,

Einar Thorsrud said:

Yes. For the other libraries etc. you use, it varies both on what you do and how you use it. Only NUS will not cause any issues, as that is just bluetooth. But do you also use UART? And is that always enabled? If so, the current consumption will be significant. So you should disable UART when you don't need it, and re-enable when you do. And logging you should disable for your production builds, as logging over UART will keep a UART instance the HW clock always running. 

I have not initialized the UART, but I still have the NRF_LOG_INFO messages and the logs are still enabled in the sdk_config.h file.

Regards,

Joel

[Einar Thorsrud]

I see. Then I would expect that you should get a low power consumption, comparable with what you see in the online power profiler. Have you checked to see if that is the case?

[jinvers]

May be. It's difficult to say because there is more HW in the middle. I have to check it better.

[Einar Thorsrud]

Sounds good. One other thing, though. Remember to not debug while measuring the current consumption. So if you have been debugging, you should do a reset before measuring current consumption, and make sure to not attach a debugger.

[jinvers]

Thanks Einar. I have found this.