BLE scan stalls on nRF52840 after several days of successful scan (NCS 2.9.0) (no connections)

RE: BLE scan stalls on nRF52840 after several days of successful scan (NCS 2.9.0) (no connections)

sarbishei — Sat, 10 May 2025 13:01:26 GMT

Hello Gavin,

I have had no luck in reproducing the same behavior using the NCS scan_adv sample with PPI trace active for radio scan while deactivating the ble adv mode from the example. My nrf52840dk board after a week or so was simply going frozen with the leds are being OFF as if it lost power completely. Every time this happened I had to power cycle the board manually. This is not the same issue as the device was going completely shutdown, but it has blocked me for running such long duration tests.

For our project, I temporarily added a software workaround for the moment that if for an extended period of time (say 1hr) no beacon is captured by the ble scan, we perform a soft reboot on nrf52. This is not a solution, but we had to add the patch as we were on a deadline to release a version for our client.

In my spare time I will keep investing this issue, as it is quite important for us and our clients. I will try to put more updates on this thread in the coming days.

RE: BLE scan stalls on nRF52840 after several days of successful scan (NCS 2.9.0) (no connections)

Gavin — Sat, 10 May 2025 08:07:07 GMT

Hi Bro,

How's it going now? I encounter the same issue.

RE: BLE scan stalls on nRF52840 after several days of successful scan (NCS 2.9.0) (no connections)

sarbishei — Tue, 04 Mar 2025 19:16:14 GMT

Thank you for the responses Jakob and Hung. I will use an example in the SDK like scan_adv, while removing the advertisement part (scan only), and attach a PPI to the radio event "NRF_RADIO_EVENT_END". I will also use PASSIVE_SCAN as done by the example provided by the SDK NCS 2.9.0. We used ACTIVE_SCAN since our target beacon is a legacy BLE device with limited payload size, and the scan response would have been helpful to add some more info to the advertisement packet. For now, we won't have to add that option. I will track the GPIO pin (corresponding to the radio events) using a logic analyzer. We should be seeing the pin toggle constantly. I would like to keep the JLINK/RTT console active via USB to track logs, so the power measurement will not be precise. I think the PPI and GPIO state already would help a lot to track this issue. I will launch the test and I would probably have to wait for a week or so to see if the blockage takes place or not. I will keep you posted. Thanks again.

RE: BLE scan stalls on nRF52840 after several days of successful scan (NCS 2.9.0) (no connections)

Hung Bui — Tue, 04 Mar 2025 14:10:08 GMT

Hi Omid,
Besides what Jakob suggested, I would suggest to try connect the Radio event (RX_END for example) to a GPIO using a PPI.
This way you can check if the radio is still doing scanning or not. You can also use the PPK2 to check the power consumption to see if the radio is active or not.

Do you see the same issue if you test with a stock sample in the SDK ? or when you test your application with earlier SDK ?

RE: BLE scan stalls on nRF52840 after several days of successful scan (NCS 2.9.0) (no connections)

Jakob Ruhe — Tue, 04 Mar 2025 08:54:40 GMT

Hello,

Problems like these can indeed be tricky to find a solution for.

A Bluetooth Packet Sniffer is a very valuable tool in this case to understand exactly what your device is doing. The one I shared is a minimum-must-have tool. There are more advanced tools available of course.

I notice that you are doing Active Scanning. Is there any reason for this? How often do you want your device to send out SCAN_REQ packets?

You say that you are using a filter. How has that been implemented?

Try to share a minimal application that can be used to reproduce the issue so that others can try it.

Can the issue be triggered faster (or not at all) depending on the number of surrounding devices?

Now that you know there is some problem I think you should try to fix it. That said, a work around which you should consider regardless is to design your system so that you do scheduled reboots every day or so. Some may think this is a very bad idea, and in some systems it is of course not possible. But quite often it can turn out to be a good approach. Sorry for going a bit out of topic but perhaps consider to have a brainstorm session about that and discuss pros and cons.

Someone with more insight than me can hopefully find something interesting in the logs you have shared. If you share an application I can run it.

Best of luck!