pc-ble-driver-py, mtu size, data length extensions and connectivity firmware

[john23094]

Hi,

I'm trying to develop an application that uses an nrf52840-dk board and the pc-ble-driver-py. The dk is supposed to be a central device.

Using the python driver library, I've got it to connect to another custom board (supposed to be a peripheral), that also uses an nrf52840 MCU. When it connects however, the custom board is supposed to negotiate a higher MTU size, packet data length extensions, and connection interval. It always does this when I connect to nRF connect on my smartphone, or anything else. But I can't seem to get it to do this with the dk and ble-driver-py. It connects, but never seems to negotiate anything. Should I make the dk (the central) try and negotiate?

The dk is flashed with connectivity firmware version: 4.1.4. SoftDevice API version: 5.

Is this a limitation of the driver and connectivity firwmare version? I can't find anything in the driver code relating to it. 

I'm also quite confused with the state of the pc-ble-driver and connectivity firmware. Can you confirm if the following is correct?:

• pc-ble-driver-py supports up to SD api v5 only, and s132 SD only
• Is there any way I can use SD s140 and v6 API? that's what my custom peripheral MCU is programmed with

[Hung Bui]

Hi Savvn,

According to the answer from our colleague Terje here. It seems like a control message to set up the UART communication and may have something to do with lost power on the connectivity chip. It may not be the case with your setup but we need to look into why it happens. 

Have you checked if there is anything special with the write command ? Is the payload large  ? Any write command would cause the issue or only that specific command ? 

If you simply test with for example heart rate collector do you see the same problem ? 

[john23094]

Hi Hung,

(I never manage to find these other forum posts - I searched for 'pc-ble-driver Target Reset performed notification' or similar, maybe I'm not searching correctly)

My first assumption was something similar, so I did try connecting the dongle directly to a USB port on my laptop - in case it was a hub/similar causing the issue. But no avail. I literally unplugged everything from my machine and only connected the dk directly. (the peripheral device is powered off an other USB pwr source).

I've already done the MSDDisable Jlink work around.

The write cmd isn't large, it's literally 1 btye.

Any other write command seems fine, it's this exact chain of events you see in the log:

• Do a write cmd
• Recv a notification (of 1 byte) about150ms later
• For some reason PC sends LINK_CONTROL_PACKET and resets the dk

Heart rate collector example works fine.

[Hung Bui]

Hi Savvn, 

It's strange the hr collector works but yours doesn't. Could you try to check the difference between the two ? As far as I know the hr collector also do a write command to enable notification and then receive notification after that. 

Maybe you can just test by modify the hr collector to use your service&characteristic UUID and then do the same write ? 

Is there anything in the notification can cause the firmware/python to crash ?