nrfxlib v3.0.2: BLE scanning results stop being reported

I have several applications that continuously scan on Bluetooth that have started exhibiting a new failure mode after upgrading nrfxlib from v2.9.0 to v3.0.2 (https://github.com/nrfconnect/sdk-nrfxlib/tree/v3.0.2).

After a variable time (but usually several hours) of continuous scanning on the extended advertising channels, no new advertising reports are generated. No errors are reported (at LOG_WRN or LOG_ERR).

static const struct bt_le_scan_param scan_param = {
	.type = BT_LE_SCAN_TYPE_PASSIVE,
	.options = BT_LE_SCAN_OPT_NONE,
	.interval = BT_GAP_SCAN_FAST_INTERVAL_MIN,
	.window = BT_GAP_SCAN_FAST_WINDOW,
};

void scan_start(void) {
   bt_le_scan_start(&scan_param, scan_cb);
}

This error state persists even if the scanning is restarted (below was my attempt at a watchdog to recover from this error). No errors are reported, but advertising reports do no restart.

static void scan_cb(const bt_addr_le_t *addr, int8_t rssi, uint8_t adv_type,
		    struct net_buf_simple *buf)
{
	/* Advertising packet observed, reset watchdog */
	k_work_reschedule(&scan_watchdog_work, K_SECONDS(60));
	...
}

static void scan_rx_watchdog_expired(struct k_work *work)
{
	int rc;

	LOG_WRN("Scan RX watchdog expired, restarting scan");
	rc = bt_le_scan_stop();
	if (rc != 0) {
		LOG_ERR("Failed to stop scanning (%d)", rc);
	}
	rc = bt_le_scan_start(&scan_param, scan_cb);
	if (rc != 0) {
		LOG_ERR("Failed to restart scanning (%d)", rc);
	}

	/* Restart the watchdog */
	k_work_reschedule(&scan_watchdog_work, K_SECONDS(60));
}

[02:42:42.781,341] <wrn> epacket_bt_adv: Scan RX watchdog expired, restarting scan
[02:43:42.785,308] <wrn> epacket_bt_adv: Scan RX watchdog expired, restarting scan
[02:44:42.787,445] <wrn> epacket_bt_adv: Scan RX watchdog expired, restarting scan

This exact same code flow (minus the watchdog) previously worked without error for days/weeks of operation.

The most obvious example is from running on a nRF52840DK forwarding packets over USB, but I have also observed the same behavior on a nRF9151/nRF54L15 split host/controller application.

None of the most recent bugfixes on main look to address this, since the application is only scanning: https://github.com/nrfconnect/sdk-nrfxlib/blob/main/softdevice_controller/CHANGELOG.rst#main-branch

All the SDC Kconfig options from the application

#define CONFIG_BT_LL_SOFTDEVICE_HEADERS_INCLUDE 1
#define CONFIG_BT_LL_SOFTDEVICE 1
#define CONFIG_BT_LL_SOFTDEVICE_BUILD_TYPE_LIB 1
#define CONFIG_BT_LL_SOFTDEVICE_MULTIROLE 1
#define CONFIG_BT_LL_SOFTDEVICE_INIT_PRIORITY 40
#define CONFIG_DT_HAS_NORDIC_BT_HCI_SDC_ENABLED 1
#define CONFIG_BT_CTLR_SDC_ALLOW_PARALLEL_SCANNING_AND_INITIATING 1
#define CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT 1
#define CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT 7500
#define CONFIG_BT_CTLR_SDC_CONN_EVENT_EXTEND_DEFAULT 1
#define CONFIG_BT_CTLR_SDC_CENTRAL_ACL_EVENT_SPACING_DEFAULT 7500
#define CONFIG_BT_CTLR_SDC_TX_PACKET_COUNT 3
#define CONFIG_BT_CTLR_SDC_RX_PACKET_COUNT 2
#define CONFIG_BT_CTLR_SDC_SCAN_BUFFER_COUNT 3
#define CONFIG_BT_CTLR_SDC_PERIODIC_SYNC_BUFFER_COUNT 3
#define CONFIG_BT_CTLR_SDC_RX_PRIO 6
#define CONFIG_BT_CTLR_SDC_LE_POWER_CLASS_1 1

Parents Reply Children
  • Hi,

    Yes, this is not ideal. However, as long as extended advertising channels are scanned and you do not have full control of the incoming packets, you cannot be guaranteed that a packet that trigger is is not received. No advertising report events are triggered after the issue has occurred.

    Another potential temporary and dirty workaround if extended scanning is needed could be to use a timer or similar (or just use the watchdog) and if no advertising reports has been received in a certain amount of time, reset. But for a proper fix you will unfortunately have to wait for the next release with this fixed in the SoftDevice Controller.

    PS: The issue will be fixed in main soon, hopefully later today or tomorrow if you do not want to wait for the official release before testing the fix.

Related