s140 pc-ble-driver 4.0.0 freezes when receiving too many data

[jpo38]

I have a nRF52840-PCA10059 dongle.

I have a PCA10040 dev boeard on which I programmed the ble_app_hrs_freertos_pca10040_s132 example after I modified HEART_RATE_MEAS_INTERVAL and BATTERY_LEVEL_MEAS_INTERVAL variables (lines 100 and 95 of main.c) with value 10 (10ms for 100Hz).

If I connect this fast "Nordic_HRM" using nRF Connect (it programmed my dongle with API v3 SoftDevice, I can connect and get notifications from the device.

If I connect this fast "Nordic_HRM" using heart_rate_collector_v3 or heart_rate_collector_v6 example programs (compiled from https://github.com/NordicSemiconductor/pc-ble-driver/tree/v4.0.0), then I only get a few notifications and then the app freezes.

When it's frozen, using a debugger I can see that UartBoost::readHandler is not called anymore. If I press Enter (supposed to toggle notifications OFF), I see written

"Setting HRM CCCD"

I see:

UartBoost::readHandler receives: c0 10 0 0 f0 c0 c0 d6 6e 0 bc 1 9c 11 0 0 0 61 3e c0
SerializationTransport::readHandler receives: 1 9c 11 0 0 0

But "Received write response." never shows up. Looks like the soft device freezed and does not send my anything.

When using heart_rate_collector_v2 with a old nRF51 dongle, I observe no freezing.

When using heart_rate_collector_v3, I kept the SoftDevice programmed by "nRF Connect". Also tried with connectivity_4.0.0_usb_with_s132_3.1.0.hex, same behaviour observed.

When using heart_rate_collector_v6, I used connectivity_4.0.0_usb_with_s140_6.1.0.hex.

"Nordic HRM" unmodified device (low sampling rate) does not freeze.

Any ides what could cause this? What does nRF Connect make differently than heart_rate_collector sample?

[Jørgen Holmefjord]

Hi,

Could you check which connection interval nRF Connect and the HR collector example is connected to the peripheral with? If you decrease the sample interval without lowering the connection interval, you might fill up the notification buffers, resulting in the device getting an error code and crashing. Can you also post the log output from the HR collector example that is output to the terminal when you run it?

Best regards,
Jørgen

[Jørgen Holmefjord]

Can you provide the modified HRS example, or did you only change the two parameters? If you could also provide a sniffer trace between the two connected devices with both pc-ble-driver and nRF Connect, that would also be helpful.

[jpo38]

Unfortnately, I'm not allowed to do that....

[jpo38]

Hello Jørgen,

As you cannot reproduce the problem and as I can on many different computers here, I was wondering if there could be a problem with our Windows setup (like using wrong drivers, or having the antivirus, firewall mess things up or whatever).

So I took a different computer, formatted the drive and did two tests:

- Installed Windows 7 (Enterprise with SP1 x64)
- Simply installed nrfconnectsetup260.exe (to get the good driver and have the dongle appear in Device Manager, it show up as "nRF Connect USB CDC ACM" driver info reports "1.0.1.0" "11/05/2018")
- Installed vc_redist.x64_2015.exe as nrf-ble-driver uses VS2015 runtimes
- Downloaded nrf-ble-driver-4.1.1-win_x86_64.zip from github
- Unzipped it, ran heart_rate_collector_sd_api_v3.exe COM3
- Pressed Enter, got ~15 notifications and nothing more: so I could reproduce the bug

Again, formatted the drive and:

- Installed Windows 10 (Enterprise version_1703)
- Did not even installed nrfconnectsetup260.exe (as the dongle appears directly in Device Manager)
- Installed vc_redist.x64_2015.exe as nrf-ble-driver uses VS2015 runtimes
- Downloaded nrf-ble-driver-4.1.1-win_x86_64.zip from github
- Unzipped it, ran heart_rate_collector_sd_api_v3.exe COM3
- Pressed Enter, got ~15 notifications and nothing more: so I could reproduce the bug

So there is definitely a problem with this driver and it does not come from my setup here.

- Either your machine has something installed/configured that makes it work better than mine
- Either I did not explain you correctly how to reproduce the issue

Could you please test from a freshly installed Windows (following the steps above)?
Also, can you confirm that when you start notifications with the device from nRF Connect, it sends you frame of data of 20bytes long. And can you also confirm that when you run heart_rate_collector_sd_api_v3.exe program you get lots of data during one second, not only one per second as the standard "Nordic_HRM" app behaves?

Kind regards,

Jean

[Jørgen Holmefjord]

Hi,

Sorry for the very slow response to your request. Unfortunately, I do not have a freshly installed Windows PC to test with, but I will try that if I find one available soon. I did a test on a different computer, but neither on this one, I'm able to reproduce your issue. I had some of the tools installed from before, so the setup is not completely identical, but I did follow your exact steps to run the test.

I can confirm that I receive 20 bytes with nRF Connect and that I receive much more frequent notifications than one second. After a while, the notifications slows down, but I believe that this is caused by the connection parameters being updated.

Best regards,
Jørgen

[jpo38]

Thanks for the update.

And what about this similar issue you mentioned: https://devzone.nordicsemi.com/f/nordic-q-a/42661/nrf-52840-hang-out-and-no-more-notification-connectivity-v3-s132-usb/192546#192546. Any progress on that? It looks similar.

The behaviour you observe (receiving a lot of 20bytes  packets for a few seconds and later slowing down) is what I observe when things work right, but in almost all situations, it freezes during the first second. And yes, the fact that it slows down is due to parameters being updated.

I'm convinced that if you test this on a freshly installed Win10 you should be able to reproduce the issue, if not, then the hardware may be different (of configured/programmed differently).

Kind regards,

Jean

[jpo38]

Hi,

Have you made any progress on this issue?

Kind regards,

Jean