I have nrf52840 DK board, running cutom image that implements BLE central, constantly scanning on coded (S8) phy. Trying to add NFC T2T tag, and it doesn't work. Disabling BLE - T2T tag works flawlessly. It looks like SoftDevice is intentionally doesn't allow to be pre-empted by any interrupts, including NFC
Hence the question - can these two (BLE Central and NFC tag) coexist ? Is there a recommended timing pattern to stop scanning to get NFC a chance to run ?
Example would be great.
PS I'm on NCS 2.1.2 but if there are newer versions that addresss this issue somehow I'll gladly upgrade to newer
AI provided satisfactory answer, but still publishing for posterity:
Can BLE Central and NFC Tag Coexist?
Yes, they can coexist, but continuous Bluetooth LE scanning—especially with a 100% duty cycle (where
scan_window == scan_interval)—causes severe resource starvation.The SoftDevice Controller runs timing-critical radio operations with the highest interrupt priority. While Bluetooth LE scanning is active, the radio peripheral and highest-priority CPU interrupts are monopolized by the Bluetooth stack. Scanning requires significant processing time and will block or starve lower-priority activity and asynchronous events [Multiprotocol support].
Because NFC Type 2 Tag (T2T) operation depends on strict frame timing response windows to communicate with an external polling device/phone, high-duty scanning will interrupt or starve NFC event handling, resulting in communication timeouts.
Recommended Timing and Duty Cycle Strategies
The knowledge sources do not explicitly specify exact timing numbers tailored specifically for concurrent NFC Tag and Coded PHY scanning. However, based on how the SoftDevice Controller schedules scanning and coexistence:
-
Reduce the Scan Duty Cycle: Do not continuously scan. Use a long scan interval with a shorter scan window to free up the radio and CPU for other activities [Concurrent SoftDevice and Bluetooth mesh activity; Bluetooth LE and Thread coexistence].
-
Note that the Coded PHY (S8) has significantly longer packet transmission/reception durations on-air, so large scan windows will keep the radio occupied longer.
-
As an example for general coexistence, parameters such as an interval of 100 ms with a window of 25 ms (25% duty cycle) or 60 ms interval with a 20 ms window are used to leave gaps for other protocols [Bluetooth LE and Thread coexistence].
-
-
Pause Scanning on NFC Field Detection: If you must use continuous or aggressive scanning, pause scanning when an NFC field is detected:
-
When the NFC T2T library senses an NFC carrier/field (or through the NFC sensing/callback events), call
bt_le_scan_stop(). -
Let the NFC read/exchange finish or wait for the field-lost event.
-
Call
bt_le_scan_start()to resume scanning.
-
-
Invert the Pattern (Scan Only After Touch): In applications such as touch-to-pair/commissioning, standard reference designs do not scan continuously; instead, the device waits for an NFC interaction first, parses the tag/payload, and only then starts the Bluetooth LE scanning/connection procedure [Bluetooth: Central NFC pairing].
Example: Adjusting Scan Parameters (Duty Cycling)
If your central must scan in the background, configure your
bt_le_scan_param with a reduced duty cycle instead of continuous scanning (BT_LE_SCAN_CODED_CONTINUOUS):#include <zephyr/bluetooth/bluetooth.h>
/* Configure a 25% to 33% duty cycle instead of continuous scanning */
static struct bt_le_scan_param scan_param = {
.type = BT_LE_SCAN_TYPE_PASSIVE,
.options = BT_LE_SCAN_OPT_CODED,
.interval = BT_GAP_SCAN_FAST_INTERVAL, /* e.g., 96-160 (60 ms - 100 ms) */
.window = BT_GAP_SCAN_FAST_WINDOW / 4, /* Shorter window to leave time for NFC */
.timeout = 0,
};
int start_duty_cycled_scan(void)
{
return bt_le_scan_start(&scan_param, device_found_cb);
}
Regarding upgrading from NCS v2.1.2: Newer NCS releases provide regular fixes and optimizations to the SoftDevice Controller and MPSL scheduling, but the fundamental constraint remains: scanning with a 100% duty cycle inherently blocks other timing-sensitive subsystems on the chip [Multiprotocol support; Concurrent SoftDevice and Bluetooth mesh activity].
