Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

  • 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;

    }

  • Hi 

    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

  • >> 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.

  • Hi ,

    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

  • >>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.

Related