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]

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.