How to obtain pc-ble-driver connectivity firmware with S132 v5.0.0 (not 5.1.0)?

[scla]

Hi,

What I would like to do:

I'm attempting to compile pc-ble-driver connectivity firmware with S132 v5.0.0. Following the instructions on the pc-ble-driver repo on Github, this compiles connectivity firmware with S132 v5.1.0, but I need version 5.0.0.

The reason I need to do this:

The device I'm working with has OpenWrt on the main chip, and a cross-compiled version of pc-ble-driver "v5" where "v5" is ambiguous. With connectivity firmware 5.1.0 burned to the NRF52 chip, I sometimes get these strange errors when calling a pc-ble-driver function (like starting a scan):

Warning: Failed to receive response for command
Status: 4, message: Error sending packet to target. Code #3

These errors have no consistent pattern. Most of the time a call to scan works, and maybe once out of 20 attempts this error will occur. The odd thing is that I cannot replicate this behavior in my dev environment on my linux rig and PCA10040 devkit running S132 5.1.0.  So I'd like to test if v5.0.0 on the production board's nordic chip to see if the pc-ble-driver version on the prod board is out-of-date. If my theory is wrong, please let me know! Thank you.

[Karl Ylvisaker]

Hello,

The odd thing is that I cannot replicate this behavior in my dev environment on my linux rig and PCA10040 devkit running S132 5.1.0.

If you never see these errors on your Linux development environment with the connectivity v5.1.0, then I would think the issue might be with the USB / COM port handling  or hardware of your OpenWRT device - could this be the case?
The error you are getting - error sending packet to target - is a common error to get when either the hardware fails directly (faulty cable, poor connection, poor solderings, etc), or when the host's COM port is not receiving/processing requests as expected. The latter issue is most prominent with Windows machines - but I have no personal experience with OpenWRT, so its worth mentioning.

Is there any physical difference between the Linux development environment, and the OpenWRT one? Do you use a different type of connection, or a different cable for instance?

Following the instructions on the pc-ble-driver repo on Github, this compiles connectivity firmware with S132 v5.1.0, but I need version 5.0.0.

So I'd like to test if v5.0.0 on the production board's nordic chip to see if the pc-ble-driver version on the prod board is out-of-date. If my theory is wrong, please let me know! Thank you.

Sure - given the ambiguity in the documentation that writes 'v5', I agree it could be worth while to check if 'v5' refers to 5.0.0 or 5.1.0.  You can compile the connectivity version 5.0.0 by going back to the latest tagged release of the pc-ble-driver repository that released with the version 5.0.0. This would be release v3.0.1 of the pc-ble-driver, you can find the connectivity firmware precompiled in the /hex directory.

Best regards,
Karl

[scla]

Note: See edit 2 for our solution.

Sorry for the late reply.

Our production board is off-the-shelf from a vendor. We have several of these devices, all exhibiting the same behavior with the same software. I'm personally not versed in hardware, but I know the main chip is a WiFi module that communicates with the NRF52 chip using a usb to uart bridge (CP2104). I've installed a kernel module "kmod-usb-serial-cp210x" (link here). In our dev environment we're just connecting an Ubuntu rig to the PCA10040 devkit with a usb cable.

We just tried using the 5.0.0 connectivity firmware. It actually still works, but we get the same behavior every so many calls to pc-ble-driver. So we're inclined to think its either the COM port or hardware. 

EDIT:

Upon inspection of the OpenWrt pc-ble-driver package code I discovered that it's definitely not up-to-date with the latest code on github but probably closer to v3.0.0 or v3.0.1. 

EDIT 2:

We flashed connectivity firmware for version 5.0.0 from the v3.0.0 release of pc-ble-driver and this error is no longer showing in our tests. The speed of connects/disconnects seems to be slower overall, but we're now bug free. It looks like this issue comes from a mismatch from connectivity firmware version and pc-ble-driver release? Our goal now is to create an OpenWrt package for the latest pc-ble-driver release.