Device Randomly Resets During BLE Scanning in Noisy Environments (nRF54L15 + NCS v3.0.2)

[Haresh05]

Hi all,

I'm working on an application using the nRF54L15 with NCS v2.9.0 and Zephyr RTOS. The device performs BLE scanning using the following parameters:

struct bt_le_scan_param scan_param = {
    .type       = BT_LE_SCAN_TYPE_PASSIVE,
    .options    = BT_LE_SCAN_OPT_FILTER_DUPLICATE,
    .interval   = 0x0100,
    .window     = 0x0010,
};

When deployed in a noisy BLE environment (e.g., multiple advertising devices nearby), the device sometimes randomly resets. This happens more frequently with the above scan parameters. Logs don’t show any fatal errors before the reset — it seems like a silent reboot.

However, if I disable BT_EXT_ADV in the configuration of sample application, the issue seems to go away and the device behaves normally even in busy environments.

But in my actual project when I disable BT_EXT_ADV, the scan start failed with error -22.
<wrn> bt_hci_core: opcode 0x200c status 0x12.  To resolve this I enabled  CONFIG_BT_EXT_ADV_LEGACY_SUPPORT and after this my actual project is also behaving normally.

I have attached the sample scan application I am testing.

I am not sure why this different behaviour in both the cases. Any insights or suggestions on this would be really helpful.

scantest.zip

Thanks!

Haresh

[Vidar Berg]

Hello,

I'm now aware of any known issues which could explain this issue. Could you please build with CONFIG_RESET_ON_FATAL_ERROR=n, watchdog disabled, and print the reset reason on boot to make sure you are able to catch any runtime errors?

Best regards,

Vidar

[Haresh05]

Hi Vidar,

Thanks for your suggestion.

I disabled the watchdog and enabled the config you suggested.
After this device does not restart but it stuck. So I enabled the BT log for debugging and found that when the packet length is large at that time device gets stuck.

Below are the last 2 packets after which device got stuck. I tried multiple times and it got stuck when the len received is 116.

Let me know what can be done in this case as none of the other device in my environment is doing extended advertising with this much size.

[2025-07-30 12:05:17] [00:00:10.575,479] <dbg> bt_sdc_hci_driver: event_packet_process: LE Meta Event (0x0d), len (56)
[2025-07-30 12:05:17] [00:00:10.575,497] <dbg> bt_hci_core: bt_recv_unsafe: buf 0x2000d69c len 58
[2025-07-30 12:05:17] [00:00:10.575,534] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[2025-07-30 12:05:17] [00:00:10.575,541] <dbg> bt_hci_core: rx_work_handler: buf 0x2000d69c type 2 len 58
[2025-07-30 12:05:17] [00:00:10.575,548] <dbg> bt_hci_core: hci_event: event 0x3e
[2025-07-30 12:05:17] [00:00:10.575,557] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0d
[2025-07-30 12:05:17] [00:00:10.575,566] <dbg> bt_scan: bt_hci_le_adv_ext_report: Adv number of reports 1
[2025-07-30 12:05:17] [00:00:10.575,615] <dbg> bt_scan: le_adv_recv: F7:5E:59:78:6E:59 (public) event 0, len 30, rssi -71 dBm
[2025-07-30 12:05:17] [00:00:10.575,649] <inf> ilumi_scan: Scan msgs recvd: 1

[2025-07-30 12:05:17] [00:00:10.580,496] <dbg> bt_sdc_hci_driver: event_packet_process: LE Meta Event (0x0d), len (116)
[2025-07-30 12:05:17] [00:00:10.580,518] <dbg> bt_hci_core: bt_recv_unsafe: buf 0x2000d404 len 118
[2025-07-30 12:05:17] [00:00:10.580,558] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
[2025-07-30 12:05:17] [00:00:10.580,566] <dbg> bt_hci_core: rx_work_handler: buf 0x2000d404 type 2 len 118
[2025-07-30 12:05:17] [00:00:10.580,572] <dbg> bt_hci_core: hci_event: event 0x3e
[2025-07-30 12:05:17] [00:00:10.580,623] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0d
[2025-07-30 12:05:17] [00:00:10.580,633] <dbg> bt_scan: bt_hci_le_adv_ext_report: Adv number of reports 1
[2025-07-30 12:05:17] [00:00:10.580,683] <dbg> bt_scan: le_adv_recv: 5F:F6:F6:1C:20:F0 (random) event 5, len 90, rssi -88 dBm

Regards,

Haresh

[Vidar Berg]

Hi Haresh,

I was made aware of this issue by a coworker, and it seems to resemble the same issue you're experiencing: nrfxlib v3.0.2: BLE scanning results stop being reported  . 

I'm working on an application using the nRF54L15 with NCS v2.9.0 and Zephyr RTOS. The device performs BLE scanning using the following param

Is this a typo, or are you seeing the issue in both v2.9.0 and v3.0.2?

Regards,

Vidar

[Haresh05]

Hi,

Earlier I was working on v2.9.0 but when I enabled FEM module I got the runtime error in that so I updated to v3.0.2

so yes currently I am working on v3.0.2 only.

Regards,

Haresh

[Vidar Berg]

Thanks for confirming. In the code you posted it seems like you are passing the wrong length argument to memcpy here:

Shouldn't it be:

The scan report can exceed 32 bytes when scanning extended adv. packets.

Regards,

Vidar

[Haresh05]

Hi,

I have made the changes and it seems to work but before that I also changed the SCAN_MSG_MAX_LEN macro to 150 and tried but even then it was getting stuck.
So I am not sure what is the final solution for this or this behaviour is due to the issue you mentioned here?

Vidar Berg said:

I was made aware of this issue by a coworker, and it seems to resemble the same issue you're experiencing: nrfxlib v3.0.2: BLE scanning results stop being reported  . 

Regards,

Haresh

[Vidar Berg]

Hi Haresh,

Yes, it's possible that the buffer overflow was only part of the issue. Have you been able to reproduce the problem after fixing it? The other issue from the linked ticket is still being investigated internally. Hopefully there will be an update on it soon.

Regards,

Vidar