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.

[Dymek117]

Unfortunatelly I'm not able to share my code :( Maybe i can create some sample next week.

But to make long story short - everything works fine with one thread (even without assert), but when two threads are running CONFIG_ASSSERT=y is necessary - otherwise bluetooth will be working fine, only until next thread will be started.

[Simon]

If your code is confidential, I can make this ticket private, so only the support engineers here at Nordic has access to the content. 

Could you try to enable some more logging? Set these and reproduce the failing state

CONFIG_LOG=y
CONFIG_BT_DEBUG_HCI_CORE=y
CONFIG_BT_DEBUG_HCI_DRIVER=y

and see if you get any information about why it fails.

[Dymek117]

I tried with example app from nordic and it works with assertion turned off.
I will try to collect more logs or maybe we will rise private tickets.

But I also have new idea now - is it possible that cause of BT working not properly is that we totally removed zephyr console from our project?

[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.