Why having "nRF Connect - Bluetooth Low Energy" open makes my connection faster and more stable

[jpo38]

I am using a nRF52840-PCA10059 dongle to acquire data at a high rate (between 50Hz and 400Hz).

The connection is very unstable, after some seconds of acquisition, it sort of freezes: looks like the softdevice crashs as we stop receiving notifications and it won't respond to read/write requests (however we do not receive any information regarding a connection being lost).

I already reported a case here and it has never been fixed:

https://devzone.nordicsemi.com/f/nordic-q-a/44922/s140-pc-ble-driver-4-0-0-freezes-when-receiving-too-many-data

Surprisingly, we just noticed that having "nRF Connect - Bluetooth Low Energy" app opened (even if not connected to the dongle, just opened in Windows) makes everything work better:

- The services dicovery is much faster

- The connection is prefectly stable. I can receive notifications for hours

As soon as I close "nRF Connect - Bluetooth Low Energy", my other application stops receiving norifications an I observe the freeze.

Apparently, "nRF Connect - Bluetooth Low Energy" does something in the background that makes the dongle and/or the soft device be more stable. What could it be?

[Jørgen Holmefjord]

Hi,

This sounds very strange. I now have a PC with an OS that has not been used for Bluetooth before. I will try to reproduce the behavior you describe on this one this week. Unfortunately, I have not received any feedback from our developers if they have managed to reproduce this yet.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

I did, in fact, manage to reproduce it. I tested both on the nRF52840 Dongle and the nRF52840 DK using the nRF_USB connector (both running the USB connectivity firmware), and they both stop after 15-20 notifications. In order to get more logs, I built the connectivity FW with RTT logging enabled. When I retried the test with the J-Link RTT Viewer open, I was no longer able to reproduce the issue.

I will try to do some more debugging, and also check with the developers again if they have had time to look into this.

Best regards,
Jørgen

[jpo38]

Unfortunatley, my collegue still experiences the same freezing even with the new .hex file.

Dues to the lockdown, I'm working from home, I should be on site on Friday and then we can work together to try to understand why the problem is apparently fixed for me but not for him.

I'll let you know.

Kind regards,

Jean

[jpo38]

Hello Jorgen,

My collegue was using connectivity_4.1.1_usb_with_s140_6.1.1_critical_region_fix_increased_sched_queue_size.hex. Now we tested with 200505_ble_connectivity_s140_usb_hci_pca10056_lfxo_mergedsoftdevice.hex and everything works better. Even if the service discovery is still slower when "nRF Connect - Bluetooth Low Energy" is not running, the connection is stable and does not freeze anymore.

We can consider this issue as fixed!

Was this bug fix added to your software trunk? Wa are using pc-ble-driver 4.1.1, when next version will be released, the hex files published will include this fix?

Thank you again for your help!

Kind regards,

Jean

[Jørgen Holmefjord]

Hi,

That is great news! The fix for both issues will be included in the next SDK release that will come soon. After that, we will look at adding the fixes to an official pc-ble-driver/connectivity FW release.

Best regards,
Jørgen

[jpo38]

All right, How can I track the change to know if it's included when a new pc-ble-driver release is done? Is there a case number or something?

Kind regards,

Jean

[Jørgen Holmefjord]

The internal case number is NCP-2437, but unfortunately, we do not have any external bug tracking system for pc-ble-driver. I will let you know once the release is available. SDK 17.0.0 was released yesterday, which should include the fixes in connectivity firmware. The pc-ble-driver team will start working on the release soon.

[jpo38]

Great! Thanks.

Last pc-ble-driver was a while ago!

[jpo38]

Hello,

I see pc-ble-driver 4.1.2 was released few days ago, it mentions "Fixed an issue where USB connectivity firmware hangs after receiving many notifications".

Is that related to this current issue? So the provided hax files should work as well as the one you sent in this post?

Kind regards,

Jean

[Jørgen Holmefjord]

Hi,

I was just about to inform you about this release. Yes, this is the release that fixes this issue. The described fix can be seen in nRF5_SDK_15.3.0_connectivity.patch on line 875-876:

+#elif defined(SER_PHY_HCI_USB_CDC)
+#define SER_CONN_SCHED_QUEUE_SIZE             64u

And on line 35728-35737:

+        CRITICAL_REGION_ENTER();
         if (nrf_sdh_is_suspended())
         {
             // Resume pulling new events if queue utilization drops below 50%.
@@ -242,6 +342,7 @@ int main(void)
                 nrf_sdh_resume();
             }
         }
+        CRITICAL_REGION_EXIT();

Best regards,
Jørgen

[jpo38]

Fantastic, I'll test this last release then!