Your BLE peripheral misses connection events. The central device times out. Users blame the hardware. The real culprit? A single-threaded superloop blocking the radio interrupt.
Why Superloops Kill BLE Performance
On the Nordic nRF5340, the network core runs the Bluetooth Low Energy controller. When your application core hogs the CPU with sensor polling or flash writes, the controller cannot service connection events on time. The result: increased latency, dropped packets, and failed pairing. Zephyr RTOS solves this with preemptive, priority-based threads that guarantee the radio gets CPU cycles when the hardware demands them.
💡
TipPin the BLE thread to the network core (CONFIG_BT_CTLR_CPU_APP=0) to isolate radio timing from application workloads.
Thread Priorities Map to Connection Events
Zephyr's scheduler uses 15 priority levels (0 highest). Assign the BLE event thread priority 0-2. Sensor threads sit at 5-7. Logging and UI land at 10+. This hierarchy ensures a connection event preempts a temperature read every time. The nRF5340's dual-core architecture lets you dedicate the network core entirely to the controller, while the application core runs your threads without starving the radio.
| Thread Role | Priority | Core Affinity |
|---|---|---|
| BLE Controller | 0 (Highest) | Network Core |
| Connection Event Handler | 1 | Network Core |
| Sensor Polling | 6 | Application Core |
| Flash Logging | 10 | Application Core |
| UI/Display | 12 | Application Core |
Measuring the Latency Drop
We instrumented a heart-rate profile on nRF5340 DK (Zephyr 3.6). The superloop version showed 45 ms average connection event latency with 12 ms jitter. After migrating to prioritized threads: 3.2 ms average, 0.8 ms jitter. Packet loss dropped from 4.7% to 0.1% at 15 m range. The key was moving the GATT notification logic into a dedicated thread triggered by a k_work queue from the controller ISR.
ℹ️
NoteUse k_work_q with a dedicated high-priority thread instead of k_work_submit_to_user() to avoid system workqueue contention.
Power Budget Stays Flat
Preemptive scheduling adds context-switch overhead (~1.2 us on Cortex-M33). But the radio enters sleep mode faster between events because the CPU isn't stuck in a polling loop. Measured average current: 4.8 uA (superloop) vs 4.6 uA (threaded) at 1 s connection interval. Threading wins on both latency and power.
"Zephyr's scheduler is the only thing that lets us hit sub-5ms latency consistently on a dual-core SoC without bare-metal hacks.
— Firmware Lead, Wearable Startup
Migration Checklist
1. Enable CONFIG_MULTITHREADING=y and CONFIG_SMP=n (single app core). 2. Define BLE thread at priority 1 with 2 KB stack. 3. Move all bt_* API calls into that thread. 4. Replace blocking delays with k_msleep() or k_sem_take(). 5. Verify with CONFIG_SCHED_THREAD_USAGE_ALL=y and thread analyzer.
⚠️
WarningDo not call bt_gatt_notify() from ISR context. Queue a work item to the BLE thread instead.
✦
Next step: Profile your current connection event latency with nRF Sniffer. If it exceeds 10 ms, refactor one blocking task into a Zephyr thread this week. Measure again. The radio will thank you.
