pc-ble-driver-py hangs while receiving notifications

[picben]

I am having a strange issue while using pc-ble-driver-py to perform tests with a BLE peripheral:

In these tests, the Peripheral sends a lot of data as fast as possible using notifications with a MTU of 126 to the Central device. In this case, the Central is a nRF52 DK with the pc-ble-driver connectivity firmware connected via USB to a Windows 10 machine. After about 30 notifications (depending on the configured GAP event length, this figure can vary), the python script for our test seems to hang up and notifications are not received anymore. If I reduce the data rate sent by the Peripheral, all notifications are received successfully. 

Here is where it gets strange, if I do the following two things, all the notifications are received successfully by the python script with the maximum data rate and the test is successful. I have to:

• Use another version of the JLink CDC UART Port driver (using v6.0.2601.5 from August 2018 instead of v1.34.0.44950 from June 2019)
• Open J-Link configurator and keep it open as long as the test is running

Do you have any idea about where this issue comes from ? I am aware that this issue is probably related to J-Link drivers but just in case you know what is happening.

More information about my setup:

• J-Link software package v6.60e, coming with Nordic command-line tools v10.6.0
• J-Link firmware on the nRF52 DK is dated 2019 Jan 7 14:07

[tesc]

Hi,

We have previously experienced some issues with the programmer MCU on our devkits, and certain J-Link firmware versions seems to work better than others. From what I understand those issues have since been fixed, so if using the latest firmware for the interface MCU you should see a minimal number of issues.

There is still a known issue when Mass Storage Device is enabled for the interface MCU. When MSD is enabled, the operating system of the PC will see the board as a storage device, and may decide to do something to it (such as indexing the files, etc.) This has primarily been an issue for Mac OS X, but I would not be surprised if similar issues may arise for other operating systems as well.

Workaround for Mass Storage Device related issues:

Use "J-Link Commander" and issue the command "MSDDisable", then reset the board. This will disable Mass Storage Device for the interface MCU. If you need to enable it on a later point in time you can do so with the command "MSDEnable".

It is also possible to omit the interface MCU entirely, for instance by using the nRF52840 Dongle (which does not have an interface MCU and instead uses the USB of the nRF52840 directly for serialization.)

We have also seen some times that the bridge between USB and UART in the interface MCU hangs. We saw this issue around five years ago. Then we started using a controllable USB hub with which we can turn power for individual USB ports off and on again from the PC in order to programmatically reset the DK. Doing so at the beginning of each test session has been part of our internal test setups ever since, and this has been a well working solution for us. The particular USB hubs we are using are the ones from Yepkit. I am sure there are other similar products out there as well.

Regards,
Terje

[picben]

Thank you for the different tips.

So far, I have tried disabling MSD on the board without success. I don't have access to a hub that would allow me to programatically turn off the DK but I have tried performing a power cycle using the power switch on the board before the test and it doesn't change anything.

I think I will go on with my current setup for the time being.

[tesc]

Hi,

I am sorry to hear that previously known solutions to similar issues do not work. At least there is the workaround of your current setup.

Regarding J-Link firmware for the interface MCU of the DK, and J-Link software package / CDC drivers, in theory using both from the same time period would be a better proven and tested combination with higher rate of success. It may be worth testing other combinations of release versions / dates than the combination you have found to be working with the caveat that J-Link Configurator must be running for things not to fail. In particular firmware and software pack released on the same date.

Regards,
Terje