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.

[Simon]

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

[Dymek117]

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.

[Dymek117]

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

[Simon]

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

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