SoftDevice consuming too much CPU when BLE connection poor.

[owl-wy7n]

We're using an nRF52840 with S140 SoftDevice.  It's configured as a peripheral device.  Our application uses FreeRTOS with several cooperating tasks.  When connected with the central (iPhone app), it typically uploads quite a bit of data to the central.

When BLE signals are fairly strong everything works well.

However, if signals get weak we've observed the SoftDevice consume an inordinate amount of CPU, starving important FreeRTOS tasks for many seconds.

Is there something we can do about this?  Could tweaking connection parameters help?  Which parameter settings are likely to help in this use case?

Do you have any suggestions on how to troubleshoot what is going on?

Thanks!

Bruce

[ovrebekk]

Hi Bruce

It doesn't really make sense that the SoftDevice would consume a lot of CPU just because of a weak signal. Quite on the contrary, if you are unable to get packets through the SoftDevice will be idle most of the time. 

What led you to this conclusion?

Are you trying to send a lot of data?
In that vein, what happens if the SoftDevice buffers fill up and you are unable to send the data that you want?

What connection parameters are you currently using?
A longer connection interval in general will reduce SoftDevice CPU usage, since you will have less Bluetooth events to handle. 

As for troubleshooting one of my colleagues suggested the following tool to help monitor FreeRTOS thread usage:
https://wiki.segger.com/FreeRTOS_with_SystemView

Best regards
Torbjørn

[owl-wy7n]

You wrote, "...what happens ...if the buffers fill up and you are unable to send the data..."

That is very likely the problem.  I found a couple instances in our code where the send operation is immediately tried again with no delay.  That is surely the problem.  The task doing this needs to delay, giving up the CPU for a while.  Otherwise it will starve lower priority tasks.

Thanks for the help!

[ovrebekk]

Hi Bruce

This is a common situation. Essentially the stack will return NRF_ERROR_RESOURCES if the internal buffers are full, and at this point there is no point trying to send anything else until the TX event occurs (BLE_GATTS_EVT_HVN_TX_COMPLETE normally). 

There are some existing devzone tickets discussing this in more detail, such as this one. 

Best regards
Torbjørn