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.

[Jørgen Holmefjord]

I'm having some issues with reading the sniffer logs. Did you use the new nRF Sniffer v2? Which Wireshark version do you use?

[jpo38]

Hello,

I used old v1_2, followed this user guide: https://os.mbed.com/media/uploads/nemovn/ble-sniffer_win_1.2_user_guide.pdf

Did not understand how to use newer versions. "Get started" page being empty (https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF-Sniffer/Get-Started#infotabs)....so I used the old one.

So this uses Wireshark v1.10.1.

Hoping you can finally read the logs, let me know.

Kind regards,

Jean Porcherot

[Jørgen Holmefjord]

I recommend using v2 and follow the User Guide that can be found on the DocLib.

[jpo38]

OK, I can do that. But is that needed for you to continue investigating my problem? Can you open and analyze the logs I sent with Wireshark 1.10.1 or do I need to use v2 and generate them again?

This issue starts to be a real problem for us as or devices (many working at 100Hz) can't be used anymore...

Kind regards,

Jean Porcherot

[jpo38]

I installed that today, please let me know if I should re-generate the wireshark logs using v2 or if you were able to analyse the ones I sent with v1.

By the way, I did some more testing today:

- Actually, "nRF Connect" also stops receiving notifications at some point (even if it takes more time for it to end up in such a situation, a few seconds).

- With API2, even after long minutes, there is no problem.

So apparently, the problem can only be reproduced with API3 or API6, and is prensent both with "nRF Connect" and with "pc-ble-driver HRM collector sample program"

Jean

[Jørgen Holmefjord]

I was able to read the logs, no need to redo them. I will try to reproduce the issue as well.

[jpo38]

OK, please make sure you reboot your machine before trying to reproduce. As I mentioned, the issue is more likely to occur after a reboot.

Looking forward to your reply,

Jean

[jpo38]

Hello,

Have you made any progress on that? Could you reproduce the issue?

Jean

[Jørgen Holmefjord]

From which SDK version did you compile the ble_app_hrm application? I tested with SDK 15.3.0 and tried to use all the same versions you used but I'm not able tor reproduce this issue.

[jpo38]

Project was compiled from SDK14.2. I attach you the hex file. It's programmed on a PCA10040 board.

I tested this again with "NRF Connect", after a fresh reboot, I constantly see the notifications stop and then device not repsonding within less than 5 minutes after I started Heart rate notifications.

Note that I just realized that we did not only change the sampling rate, we also changed the amount of data being sent: it's always 20 bytes, when regular HRM sends 2 or 3 bytes only. Sorry that I forgot to mention that.

We just tested with SDK 15.3.0 with a PCA10056 board. Just changed the sample rate, did not change the amount of data being sent. The connection was more stable. But after ~30mn, same problem: stopped receiving notifications and could not do anything with the device (no reply to read/write characterisctis/notifications requests)... 

6332.nrf52832_xxaa.hex