SDK14.1 Multilink with NUS data sent issue

[TH_HT]

I have refer to this topic for setup multilink with NUS. https://devzone.nordicsemi.com/f/nordic-q-a/18804/mismatch-between-connection-handles-in-ble_nus

But, i met a  wrong 'BLE_GATTC_EVT_HVX' event issue, below is the situation, i test with two peripheral and one central,

1.  Two peripherals connected with central

2.  Two peripherals disconnected with central a few minutes after step 1

3.  Then, if just one peripheral connect with central again, and this peripheral send data to central, then central will get BLE_GATTC_EVT_HVX event twice at each data transmission from the peripheral, that means central get two package data, the same package data twice. But the peripheral was just sent once package.

4. If the other peripheral connect again, this issue would be gone away, central will get the right BLE_GATTC_EVT_HVX event, and every data  transmission will be ok.

BTW, if only one peripheral connected with central after central power up, or two peripherals always connected with central after central power, it will be without this issue. But if anyone disconnected, this issue will be happened, until all peripherals connected, this issue will be gone...

 I don't  understand why SD triggered two BLE_GATTC_EVT_HVX event in this situation, hope Nordic engineer or someone can help on this issue.

Thanks a lot.

[WET TF]

Hi,

I have a similar issue. When I turn on the master/central and connect peripherals, I can send/receive strings like normal over NUS. Right now I have the peripherals sending back a "hi" when they receive a string over NUS. This works as expected. When I disconnect (turn off) a number N of peripherals, I start getting the expected "hi" response when sending to any peripheral that's still connected, but N+1 times. After a little debugging I found that the BLE_NUS_C_EVT_NUS_TX_EVT triggers twice, for the same connection handle. If I connect a new peripheral (even the one that disconnected), I now get one less duplicated response. 

I'm guessing it has something to do with not closing NUS instances, and I didn't quite understand how to close them when following the rabbit hole of the NUS and GATT event handlers.

[Sigurd]

Hi,

SDK 15.0 is now released and can be downloaded from this link.

In SDK 15.0 we have added multilink support for the Nordic UART Service. I recommend taking a look at the new NUS example to see how the multilink support is implemented.

EDIT:

Unfortunately, the NUS multilink support was only added for the server.

If you are only sending one packet from the server to the client, only 1 BLE_GATTC_EVT_HVX  should have been generated. Could it be that you are handling the same event twice? Feel free to upload the source code, or provide some debug nrf_logs that shows the problem.

[WET TF]

Hi,

Where is the example of multilink NUS? Neither ble_app_multilink_central nor ble_app_uart_c fit the bill. The SDK 15.0.0 release notes only say that "multilink support was added" and I see that BLE_NUS_C_ARRAY_DEF was added in NUS' API reference, but I haven't found the example implementing it.

[Martin]

I got exactly the same problem with the SDK 15.3.0 and I think I found the root cause.

It looks like there is a bug within the ble_nus_c.c at the ble_nus_c_on_ble_evt function. After a peripheral disconnects, its connection handle gets set to invalid (BLE_CONN_HANDLE_INVALID) but neither the on_hvx function nor ble_nus_c_on_ble_evt itself will discard events for an invalid connection handle. The on_hvx function only checks the TX characteristic's handle (p_ble_nus_c->handles.nus_tx_handle) for an invalid value.

As far as I can tell this can be fixed by dropping events for ble_nus_c_t instances that got an invalid connection handle within the function ble_nus_c_on_ble_evt by replacing this code...

    if ( (p_ble_nus_c->conn_handle != BLE_CONN_HANDLE_INVALID)
       &&(p_ble_nus_c->conn_handle != p_ble_evt->evt.gap_evt.conn_handle)
       )
    {
        return;
    }

... with that code ...

    if ( (p_ble_nus_c->conn_handle == BLE_CONN_HANDLE_INVALID)
       ||(p_ble_nus_c->conn_handle != p_ble_evt->evt.gap_evt.conn_handle)
       )
    {
        return;
    }

Furthermore I think that the characteristic's handles should also get invalidated during disconnect to prevent other parts of the code from thinking that a reused instances got already discovered:

                p_ble_nus_c->handles.nus_tx_handle = BLE_GATT_HANDLE_INVALID;
                p_ble_nus_c->handles.nus_rx_handle = BLE_GATT_HANDLE_INVALID;

I attached the patch that I applied to my instance of then nRF5_SDK_15.3.0_59ac345:

8203.0001-Drop-events-for-invalid-connection-handles.patch

Can someone from Nordic check, if this is really a bug within the SDK and if so, that my fix is enough to solve the problem?

BTW Is there an official GitHub repository for the SDK to submit pull requests?

[Sigurd]

Hi Martin,

You are correct. It was also reported in this case. It will be fixed in the next SDK release.

Martin said:

BTW Is there an official GitHub repository for the SDK to submit pull requests?

Unfortunately, no.