No valid bidirectional (UART) communication between the iMX6 UL-S evk board running the Nordic PC BLE driver and the nRF52 DK running the Nordic connectivity 132 uart software

[Frank]

Hallo,

Currently I'm investigating different Low Energy Bluetooth solutions for our healtcare products that we build in Televic Healthcare.

So  here is the setup I have build to verify how fast and easy we can integrate the Nordic products into our healthcare products:

As we want still  to have our own board running the application software the Exceet IMX6 UL-S 2 evk board is used (see : https://docs.exceet-electronics.de/board-imxceet-ul-2-s/) in combination with the Nordic nRF52 DK board.

Both boards are linked together via a UART connection for bidirectional communication. 

As proposed by Nordic to handle this kind of use case I have been investigating the serialize concept as described in the Nordic v15 SDK documentation.

So the Exceet board will operate as application board and the Nordic nRF52 DK board shall operate as connectivity board 

However for fast proof of concept and evaluation I found the wonderful and powerful BLE driver SW provided by Nordic distributed via GIT.

So I managed to build (cross compiling for Cortex 7A processor) and run the BLE driver SW on the Exceet IMX6 board.

As mentioned both boards are connected via a UART link. 

On the Nordic board that operates as connectivity board I flashed the connectivity_2.0.1_115k2_with_s132_5.0.hex (downloaded from GIT)

Unfortunately the BLE driver application on the application board exits after trying to send 6 times the LINK CTRL packet or better the SYNC message : 01 7e

The UART message as it was trapped by a logical analyzer. 

Debug output:

Any ideas how to proceed further, what  further debug information can be interesting for Nordic?

I also tried to use the HR connectivity SW as provided by the latest Nordic SDK v15 for debugging via the SEGGER IDE debugger.

In that case I flashed the latest SoftDevice SW and flased the HR connectivity applic SW after it was build in the SEGGER IDE. 

BTW I have also posted some comments on the github site for the BLE driver project:

https://github.com/NordicSemiconductor/pc-ble-driver/issues/143

Thanks in advance,

Best regards,

Frank Vieren

[Frank]

Hi Nordic support,

Latest update/progress:

Built and flashed  the Connectivity applic, ble_connectivity_s132_hci _pca10040 from the latest SDK v15 [nRF5_SDK_15.2.0_9412b96] into Nordic DK board operating as connectivity board.

The HCI_LINK_CONTROL define is set.

Built the latest PC BLE driver SW and ran it on the Exceet board. I have set the DEFINES NRF_SD_BLE_API=5 NRF_SD_BLE_API_VERSION=5  for compilation.

Debug output:

So I get correct bi-directional communication over the UART (HCI) between both the boards. 

The setup state machines passes at startup and response messages from the Connectivity applic running on the Nordic DK are correctly received and handled.

But the process at startup fails to set the command sd_ble_cfg_set, and exits with internal error 0x03.

When for debugging I omit/skip this function at startup, I get an error when trying to set the advertisement data.

What could be the problem? API version mismatch between SDK and PC BLE driver SD API coding?

Thanks in advance,

Frank

[Bjørn Inge]

Hi Frank,

you provided a logical analyzer trace to being with. It would be helpful to see another trace now that you have gotten past the initial setup. It might be the HWFC that is not working optimally on your setup, and a trace would give some info on that. Make sure to capture all 4 lines, RX/TX/RTS/CTS.

[Bjørn Inge]

>>I'm just wondering why is flow control  set to none by default in the PC BLE driver applic.

That's a valid question, and the reason it is set to none is that the JLink OB chip on Nordic DevKits have a auto-sensing mechanism for flow control. See the response in this thread https://devzone.nordicsemi.com/f/nordic-q-a/37763/get-no-response-from-connectivity-program-running-on-custom-board-with-pc-ble-driver-hrc-v5-example-host/146070#146070.

Since you do not have a JLink OB chip you need to find the UART settings that works for your device.

[Frank]

Hi Bjørn Inge

No luck with the HWFC setting on Boost UART, it is throwing an exception when enabling the HWFC option.

Experiencing as explained here:

https://stackoverflow.com/questions/28274367/how-to-make-boostasioserial-port-baseflow-control-use-hardware-flow-contro

UART driver issue on Exceet? Would surprise me that HWFC is not possible as CTS/RTS are provided, BOOST issue/compilation...? Any thoughts?

Also no luck with deploying the connectivity applic after applying the patch and changing the Flash placement XML file. So I can build the connectivity applic but it can no longer be deployed via SEGGER, SEGGER throws a failure message when loading up the file despite having a valid connection between PC and board.

Thanks,

Best regards,

Frank

[Bjørn Inge]

Hi,

in this case Boost does not know whether your system supports HWFC so it simply gives up. If your system supports it you can try to configure it manually. It's getting more complex as you will need to modify the source code of ble-driver (src/common/transport/uart_boost.cpp).

Some pointers:

1. Get the native handle from boost: 

fd = serialPort.native_handle(); // fd is of type int

(example: https://stackoverflow.com/questions/30618678/boostasioserial-port-set-rts-dts)

2. Use ioctl to configure the serial port settings

options.c_cflag |= CNEW_RTSCTS; /* Also called CRTSCTS */

(some info here: https://www.cmrr.umn.edu/~strupp/serial.html)

[Frank]

Hi,

Thanks, I will try it out, sounds feasible.

Br,

Frank

[Frank]

Hi Bjørn Inge

Great news, it works finally, however it only runs so far with HWFC disabled at both ends so also on the Nordic DK running the connectivity applic! 

So I think the extra thing that finally made it work was the patch and especially making the code  API v5 compatible at both ends. 

Tomorrow, I will look into it if I can get it to work with HWFC enabled, meaning getting the CTS/RTS applicable on the Exceet iMX6 board. I will tryit out with hacking the file descriptor for the serial port. 

I'm very pleased however a number of points I want to address that makes it not very confident especially about the patching and  the API  BLE driver not completely compatible with the SDK v15.

I will give a full report tomorrow of my observations during the last days of development. 

However I love  very much the concept of the PC BLE driver implementation, this is the way to go for the application board at least if the resources are sufficient enough!

Thanks again for all the support, but I will try to get it to work with the HWFC enabled and report further on the progress I make.

Best regards,

Frank

[Frank]

Hi Bjørn Inge, all,

Please find my report on the PC BLE driver concept implemented on a custom board running Linux OS. 

Nordic© PC BLE driver concept implemented on a custom board-v40-20181010_1445.pdf

Maybe most important the conclusion of  my quick succesful proto experience.

Pros:

• Very nice concept compared to having to implement yourself the UART driver functionality in plain C to support the HAL transport layer. In other words simplifies/speeds up the implementation process.
• Nice C++ implementation.

Contras:

• Use of a patch, API version 5 PC BLE driver sources not in sync with the SDK v15 API 5.
• Struggling when building the patched project, ble_connectivity_s132v5_hci_pca10040 in SEGGER IDE (flash_placement, debug build fails), this is not the case with the non-patched SDK v15 version.
  Strange because normally full support expected for SEGGER.
• Not part of the Nordic SDK, it should be see the Pros.
• Limited documentation, as far as I know no direct reference on Nordic web page cfr. SDK.

Most surprising to me, is the fact the mismatch of the API v5 applied on the connectivity and PC BLE driver application sources. Despite the mismatch I would rather expect the patch needed on the PC BLE driver application sources regarding the sd function calls. 

Also it should be part of the SDK as it is very powerful implementation that simplifies very much the development on the custom board. 

Bjorn, thanks for the support the last days, much appreciated. 

Best regards,

Frank

[Bjørn Inge]

Frankthank you for the detailed report. It is of good value to get detailed insight into end products like that. You state valid comments.

Note: I think you willl see that the build scripts and build workflow has improved in the next release of pc-ble-driver, currently consolidate-api branch.

Thanks.