Bluetooth and threading with Zephyr

[Dymek117]

Hey,
I'm trying to integrate BT + DFU functionality into my application, i'm following this example:
Add DFU support to your application - Software - nRF Connect SDK guides - Nordic DevZone (nordicsemi.com)

Everything is working fine, I can see device from nordic iOS app and even send strings. Everything fails, when i'm adding to program my own code.
I'm pretty sure that code itself isn't a problem. Please look at below examples in pseudocode:

COMBINATION THAT WORKS:

main() starts
enable BT and mcumgr OTA.
run my thread (only small inits)
my code executed in while loop, placed in main()

COMBINATION THAT DOES NOT WORK:

main() starts
enable BT and mcumgr OTA.
run thread with my code (executed in thread's while loop)

So the problem occures only when i'm executing my code in thread's while loop. When i use while in main loop everything works.
Do you guys have any idea what is going on here? Maybe I should create separate thread only for bluetooth? 

I'm using SDK 1.8.0 and nRF52832 dev board.

[ACook]

I found this thread while trying to debug some similar issues with the Bluetooth stack and multithreading on my nRF52810. I don't know if this will be helpful for your situation, but I figured I would share since this post is still "not answered".

The app I have runs a simple control API over UART in a loop in main to setup Bluetooth GATT services. I had main running at priority 0, and I noticed that pairing would never work unless I explicitly did a sleep in my loop. I saw that the BT RX and TX threads were running at negative priority, but when I dug a little deeper I noticed that the "BT CTLR ECDH" thread was running at priority 10. So I think that thread could never pre-empt main and pairing could never be initiated.

That thread gets created in the NRF Bluetooth controller (not Zephyr), so if this is not desired behavior then maybe a bug ticket needs to be created for Nordic. I also noticed that the module could crash randomly if I had main running at a higher priority than the BT CTLR ECDH, so maybe there's a crash that can happen in there if it gets pre-empted.

[ALAV]

Can confirm having a similar issue on the NRF5340 as well. The BT HCI core initializes fine and advertisements also work like a charm. But, soon as the code enters a while loop on main, connections timeout. I'm testing the connection over LightBlue. The connection only proceeds if the main loop is slowed down.

[Hung Bui]

Hi Alav, 
Please create a new case for your question. 
Please be aware that in zephyr if thread has the same priority it will not preempt each other. You need to put the thread to sleep to yield for other thread.  If you have a look here, you can find that when time slicing is not used (which is the default case) preemptive thread with the same priority will not yield to each other. 

[ALAV]

Hey Hung, We figured out that it was thread priority. The HCI_RPMSG_RX thread was set to priority 8, We had to change the main thread priority from 0 to 8.