• State Not Answered
  • Replies 29 replies
  • Subscribers 68 subscribers
  • Views 6896 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 245334
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents Reply Children
  • 0 in reply to Jørgen Holmefjord

    Hello Jorgen,

    Unfortunately, this new .hex file does not resolve the issue. Note that there is not only "nRF Connect - Bluetooth Low Energy" being opened that makes the issue disappear, we also noticed that having Keil or Visual Studio opened makes the issue disappear. Maybe you had one opened when you could run the app for 5 hours with no problem. To be sure you reproduce our issue, the best is to reboot the system and only run heart_rate_collector_v3 or heart_rate_collector_v6 without starting any other program, it always freezes within a few seconds.

    On my laptop, just after softdevice stops transmitting notifications, I receive a "serial port read on port COM5 aborted" "Debug" notification through the log_handler passed to sd_rpc_open. I was not seeing on my desktop computer. Maybe it can help.

    Please confirm that you can still reproduce the issue, as you did some weeks ago.

    Kind regards,

    Jean 

  • 0 in reply to jpo38

    Hi Jean,

    I did only verify the fix with sd_api_v3, as it was my understanding that you did not manage to reproduce this issue with sd_api_v6. Reading over the cases again, I now see that this assumption may not have been correct. I did a new test with both sd_api_v3 (where I again reproduced the issue with the old firmware, and confirmed that it's working with new firmware), and with sd_api_v6. In sd_api_v6, I can both reproduce the issue, and the new connectivity hex does not seem to solve the issue.

    This computer does not have any Nordic tools installed (nRF Connect, nRF Command Line Tools, etc), or any compilers (SES, Keil, VS, GCC, etc), so there should not be anything interfering in that way,

    I will try to run connectivity firmware with logging enabled to try to find any other issues. Can you confirm if you were able to reproduce the issue with the new connectivity hex on sd_api_v3?

    Best regards,
    Jørgen

  • 0 in reply to Jørgen Holmefjord

    OK, good to know you can still reproduce the issue.

    I can reproduce the issue with both SD API v3 and v6, and, surprisingly, none of the .hex file you posted fix it (with *_critical_region_fix.hex, I can still see notification freezing with SD API v3 and v6). So for API v3, we experience a different behaviour.

    In all 4 situations, I get this "serial port read on port COM5 aborted" "Debug" notification after notifications are stopped.

    Kind regards,

    Jean

  • 0 in reply to jpo38

    Ok, I enabled logs in the connectivity firmware and ran the test again. I see a fatal error in the log, which I traced to a NRF_ERROR_NO_MEM when a new event is added to the scheduler queue. I suspect that the high frequency of notifications cause the scheduler queue to be filled before it can be processed.

    I tried doubling the configured queue size, and I'm now not able to reproduce the issue again. Can you test with this new hex-file? connectivity_4.1.1_usb_with_s140_6.1.1_critical_region_fix_increased_sched_queue_size.hex

Related