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.

[Frank]

Hi Bjorn Inge,

Thank you for responding to my problem.

I disabled the HWFC as otherwise I don't get any response at all from the Connectivity applic running on the Nordic DK board.

The PC BLE driver runs on the Exceet IMX6 board with flow control set to NONE. I don't get it to work  at all when HWFC is enabled on both sides. 

So the Connectivity applic responses correctly on the Link Control Packets sent by the PC BLE driver applic (control packets sent in the setupStateMachine: CONTROL_PKT_SYNC, CONTROL_PKT_SYNC_CONFIG,...).

In the H5Transport::processPacket function the syncResponsePacket, syncConfigResponsePacket, etc, are well received/decoded.

It seems only failure starts when calling the sd_ble functions  (e.g. sd_ble_cfg_set, sd_ble_gap_adv_data_set, ...) failure occurs (Status 4 , message: Error sending packet to target. Code #3)

I see when adding extra debug output, the BLE driver applic gets a sync packet after "Status  7 connection active is set and the BLE driver is opened" when operating in the ACTIVE state which triggers the RESET state again... and finally the application exists.

Serial port used: /dev/ttymxc2
Baud rate used: 115200
H5Transport open...
start waiting...
start waiting...
open UartBoost... /dev/ttymxc2
opened UART ... /dev/ttymxc2
Info: Successfully opened /dev/ttymxc2. Baud rate: 115200. Flow control: none. Parity: none.

Next state = STATE_RESET
Status: 6, message: Target Reset performed
Next state = STATE_UNINITIALIZED
Got sync response packet for UNINTIALIZED
Next state = STATE_INITIALIZED
Trying to set state in active...
Got sync CONFIG response packet for INITIALIZED
Trying to set state in active...
-----> sets in STATE_ACTIVE
Next state = STATE_ACTIVE
Opened nRF BLE Driver
Status: 7, message: Connection active
Warning: Failed to receive response for command
Status: 4, message: Error sending packet to target. Code #3
sd_ble_cfg_set() failed when attempting to set BLE_GAP_CFG_ROLE_COUNT. Error code: 0x03
Got sync packet for ACTIVE STATE
Going into reset mode...
Next state = STATE_RESET

I hope this extra information helps.

Should I work with HWFC enabled in the Connectivity applic? Why is it disabled at the PC BLE driver side?

Best regards,

Frank

UPDATE: extra info

Internal error (#3)  happens as no response message is send back by connectivity applic after sd function was send by PC BLE driver applic.

uint32_t SerializationTransport::send(uint8_t *cmdBuffer, uint32_t cmdLength, uint8_t *rspBuffer, uint32_t *rspLength)
{
// Mutex to avoid multiple threads sending commands at the same time.
std::lock_guard<std::mutex> sendGuard(sendMutex);
rspReceived = false;
responseBuffer = rspBuffer;
responseLength = rspLength;

std::vector<uint8_t> commandBuffer(cmdLength + 1);
commandBuffer[0] = SERIALIZATION_COMMAND;
memcpy(&commandBuffer[1], cmdBuffer, cmdLength * sizeof(uint8_t));

auto errCode = nextTransportLayer->send(commandBuffer);

if (errCode != NRF_SUCCESS) {
return errCode;
}
else if (rspBuffer == nullptr)
{
return NRF_SUCCESS;
}

std::unique_lock<std::mutex> responseGuard(responseMutex);

std::chrono::milliseconds timeout(responseTimeout);
std::chrono::system_clock::time_point wakeupTime = std::chrono::system_clock::now() + timeout;

responseWaitCondition.wait_until(
responseGuard,
wakeupTime,
[&] {
return rspReceived;
}
);

if (!rspReceived)
{
logCallback(SD_RPC_LOG_WARNING, "Failed to receive response for command");
return NRF_ERROR_INTERNAL;
}

return NRF_SUCCESS;

}

[Frank]

Hi Bjørn Inge

I think I can manage without the wndows batch file have to build automatically the connectivity application that should be compatible with the PC BLE driver applic. Probably the correct SoftDevice hex will also be flashed automatically into the connectivity board after building and running the connectivity applic with SEGGER.

Most important is that the patch is correctly executed on the SDK v15. Except that in my case the serialize pins for UART must remain unchanged, meaning 23, 24,25 and 02 instead of 8, 6, 7, 5.

I'm still a bit worried when HWFC is enabled the connectivity applic is no longer responsive after the link control packets are sent. 

But first I will see what the patched SDKv15 solves for me.

Thanks for the support, I will keep you and the Dev Zone informed.

Best regards,

Frank

[Bjørn Inge]

>> Should I work with HWFC enabled in the Connectivity applic? Why is it disabled at the PC BLE driver side?

>> I'm still a bit worried when HWFC is enabled the connectivity applic is no longer responsive after the link control packets are sent. 

The HWFC is probably the main culprit at this point. If you disable the HWFC in connectivity you will get some traffic but then at some point the nRF5x chip UART is flooded, leading to loss of data. 

>> It seems only failure starts when calling the sd_ble functions

This proves the case for HWFC. You see failure when calling sd_ble function because those packets are longer than the initial control packets. Control packets won't lead to flooded UART, but most sd_ble functions will, meaning operative HWFC is required.

>> I disabled the HWFC as otherwise I don't get any response at all from the Connectivity applic running on the Nordic DK board.

If you have HWFC enabled and don't get any resonse, it probably means that the transmission is blocked by the Exceet IMX6 HWFC lines.

Summary: You need to have operative HWFC

Advice: Hook up the logical analyzer to the UART lines RX/TX/CTS/RTS lines to debug how and why HWFC isn't working.

[Frank]

Hi Bjørn Inge,

Thanks for the extra info, this is good to know, I'm just wondering why is flow control  set to none by default in the PC BLE driver applic. As far as I know only baudrate and portname is set. 

UartSettings::UartSettings()
	: portName("COM1"),
	baudRate(0),
	flowControl(UartFlowControlNone),
	parity(UartParityNone),
	stopBits(UartStopBitsOne),
	dataBits(UartDataBitsEight)

I will certainly when running the patched Connectivity applic monitor all the UART communication lines.

I will report back.

Thanks,

Best regards,

Frank

[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