Bluetooth and threading with Zephyr

RE: Bluetooth and threading with Zephyr

ALAV — Fri, 10 Feb 2023 02:37:21 GMT

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.

RE: Bluetooth and threading with Zephyr

Hung Bui — Wed, 08 Feb 2023 12:13:39 GMT

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.

RE: Bluetooth and threading with Zephyr

ALAV — Thu, 02 Feb 2023 05:07:19 GMT

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.

RE: Bluetooth and threading with Zephyr

ACook — Fri, 14 Oct 2022 23:07:22 GMT

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.

RE: Bluetooth and threading with Zephyr

Dymek117 — Wed, 02 Feb 2022 15:10:49 GMT

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?

RE: Bluetooth and threading with Zephyr

Simon — Sun, 30 Jan 2022 16:38:24 GMT

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.

RE: Bluetooth and threading with Zephyr

Dymek117 — Sat, 22 Jan 2022 00:48:32 GMT

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.

RE: Bluetooth and threading with Zephyr

Simon — Fri, 21 Jan 2022 13:50:36 GMT

Hmm.. It is hard to say why enabling asserts makes the issue go away. It would be much easier for me to investigate this if I get the sample, run it on an nRF52832 DK and reproduce it myself. Would it be possible to upload the sample here on DevZone (or a simplified sample that demonstrates the issue)?

Best regards,

Simon

RE: Bluetooth and threading with Zephyr

Dymek117 — Fri, 21 Jan 2022 12:16:56 GMT

It may be helpful to look info my prj.conf. This one is without asserts (so it is not working)

CONFIG_SIZE_OPTIMIZATIONS=y

CONFIG_GPIO=y

CONFIG_PWM=y

CONFIG_ADC=y

CONFIG_NRFX_TIMER0=y

CONFIG_FLASH=y

CONFIG_BT=y

CONFIG_BT_SMP=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME="Nordic_LBS"

# Enable mcumgr.

CONFIG_MCUMGR=y

# Enable most core commands.

CONFIG_MCUMGR_CMD_IMG_MGMT=y

CONFIG_MCUMGR_CMD_OS_MGMT=y

# Ensure an MCUboot-compatible binary is generated.

CONFIG_BOOTLOADER_MCUBOOT=y

# Enable the Bluetooth (unauthenticated) and shell mcumgr transports.

CONFIG_MCUMGR_SMP_BT=y

CONFIG_MCUMGR_SMP_BT_AUTHEN=n

# Some command handlers require a large stack.

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

# Disable Bluetooth features not needed

CONFIG_BT_DEBUG_NONE=y

CONFIG_BT_ASSERT=n

CONFIG_BT_DATA_LEN_UPDATE=n

CONFIG_BT_PHY_UPDATE=n

CONFIG_BT_GATT_CACHING=n

CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n

CONFIG_BT_HCI_VS_EXT=n

CONFIG_BT_CTLR_PRIVACY=n

# Reduce Bluetooth buffers

CONFIG_BT_BUF_EVT_DISCARDABLE_COUNT=1

CONFIG_BT_BUF_EVT_RX_COUNT=2

CONFIG_BT_L2CAP_TX_BUF_COUNT=2

CONFIG_MULTITHREADING=y

RE: Bluetooth and threading with Zephyr

Dymek117 — Fri, 21 Jan 2022 07:23:12 GMT

I had to return to this problem, here is my current position:

With CONFIG_ASSERT=n:

main() starts
enable BT and mcumgr OTA - Bluetooth fully responsible
delay 3s - Bluetooth fully responsible
run my thread (priority set to 18) - Bluetooth not responsible at all

With CONFIG_ASSERT=y:

main() starts
enable BT and mcumgr OTA - Bluetooth fully responsible
delay 3s - Bluetooth fully responsible
run my thread (priority set to 18) - Bluetooth fully responsible

My question is - why does enabling assertion globally solves this problem?
I would rather not includ asserts in my code, as BT appliacation with asserts weights a lot,
and i would better keep space for 2 program slots in my 512kB of flash.

It's worth adding, that my thread is not influencing bluetooth or ota features, it's simple gpio, uart operations.

RE: Bluetooth and threading with Zephyr

Simon — Mon, 17 Jan 2022 12:14:14 GMT

Hello,

I'm glad you found a partial solution. However, I'm not exactly sure what could cause this issue. Could you share a simple sample that demonstrates the issue?

Best regards,

Simon

RE: Bluetooth and threading with Zephyr

Dymek117 — Mon, 17 Jan 2022 07:40:00 GMT

Ok, I partially solved my problem. Solution was running all BT and DFU init functions in main loop (or separate thread) and setting my code's thread priority down to 18 value .
Running my code and BT inside one thread is apparently not a good idea.