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]

Hello,

I could finally install and run the sniffer.

See attached zip. There are logs for three sessions:

• Session #1 Using nRF Connect. connected HRM device, toggled notifications on, waited a few seconds, toggled them back off. See nrf_connect.txt (nRF Connect log) and nrf_connect.pcapng (Wireshark log). Everything worked fine.
• Session #2 Using HRM collector sample (juste modified it a bit to log events from UartBoost::readHandler, SerializationTransport::readHandler and timestamp log messages). See hrm_collector.txt (HRM collector log) and hrm_collector.pcapng (Wireshark log). This time the app stopped receiving notifications shortly after notifications were turned on. Note that after the HRM collector app stopped receiving data, Wirshark was still showing notifications. So this confirms that pc-ble-driver is frozen at some point but the connection between SD and the peripheral remains open and active.
• Session #3 I experienced some crashs with the sniffer. I don't know if it's related to my issue (crashed with both "nRF Connect" and "HRM collector" being used), but as it reports "Invalid packet" I was thinking it could eventually be related (could those invalid packet be badly handled by SD or pc-ble-driver?). Note that:
          - the fact that the sniffer crashs does not affect the app ("nRF Connect" and "HRM collector") itself, not even the fact that it continues receiving notifications (at least for "nRF Connect", as for "HRM collector" it's hard to say if it stopped receiving any due to sniffer crash or reported issue).
          -  in Session #1, sniffer did not crash but HRM collector stopped receiving notifications anyway, so those Invalid packet may not be related to the reported issue...  
  See sniffer_error_app.log (HRM collector log), sniffer_error_sniffer.log (Sniffer log, with "Invalid packet" reported) and sniffer_error.pcapng (Wireshark log).

Hopefully this can point you to what's going on. I have the feeling that the problem is most likely due to the driver or dongle itself freezing at some point.

Please let me know if it helps.

Note:
- dongle used for sniffing: PCA10031
- dongle used for BLE connection: PCA10059, programmed by nRF Connect with SD API v3
- board hosting "HRM" app: PCA10040

Kind regards,

Jean

100Hz with_APIv3.zip

[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