Bluetooth callback is not called occasionally in multi-threaded application

[choehyunho]

Hi team,

I am using nRFConnect SDK v2.2.0, and developing multi-threaded application which has BLE and ethernet.

I had three thread, each has the same priority of 7.

The first one is BLE central thread, and starting scan and connect, send/receive data to device, and disconnect.

The second one is running MQTT client, and waiting for message from the network.

The third one is running DHCP client and monitoring network management events.

When the second thread received message from internet, it sends signal to start BLE scan to the first thread, and by sequential calling Bluetooth event callback, the first thread is sending/receiving data to some other BLE device.

If all the bluetooth callback is called properly, the first thread will finish its function properly, but sometimes BLE callback is not called and the thread is blocked.

When I manually send signal via shell or something, it works fine, but the second thread sends signal, the callback is not called from time to time.

Specifically, after connected callback is called, no further callbacks like MTU exchange or GATT discover is called any more.

More strange point is that I schedule a delayed work to cancel work after specified timeout, but delayed work is not started, too.

I think some data related to the scheduler or work queue is corrupted, but don't know how can I fix this.

There is no crash log or error log displayed, and increasing privileged stack size does not fix problem.

[Susheel Nuguru]

Hi,
Unfortunately, I did not manage to look at this today. I will try to provide you more info on Monday. Thanks for your patience.

[choehyunho]

Hi Susheel,

Thanks for your reply.

I have tested more about this issue, and it seems to be related to thread priority.

When I send signal from k_work, the above symptom is happening very frequently.

But if I send signal from MQTT thread itself (priority 7), the problem no longer happens.

Although, my urgent problem was solved, still I want to clarify default NCS thread priority and related settings.

I reviewed some zephyr configurations, and most BLE thread has priority 6~8.

And the default priority for system workqueue is -1.

Is all these may cause problems?

Should I avoid triggering BLE in system workqueue?

I want to know what is the best practice about priority configuration in NCS.

[Susheel Nuguru]

choehyunho said:

Should I avoid triggering BLE in system workqueue?

The BLE stack also uses system workqueue so it might be possible that we are seeing some kind of race condition here. Even though it is not disallowed to use system queues to trigger BLe activity in system queue, to have a predictable behavior, I strongly susggest that you define your own thread and its own priority for the workqueue you are using.

[choehyunho]

Understood.

I may need to review Application Event Manager module to integrate various system components with BLE.

Thanks for your support.