SDK14.1 Multilink with NUS data sent issue

RE: SDK14.1 Multilink with NUS data sent issue

Sigurd — Tue, 01 Oct 2019 06:53:33 GMT

Hi Martin,

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

[quote userid="83797" url="~/f/nordic-q-a/32624/sdk14-1-multilink-with-nus-data-sent-issue/212663"]BTW Is there an official GitHub repository for the SDK to submit pull requests?[/quote]

Unfortunately, no.

RE: SDK14.1 Multilink with NUS data sent issue

Martin — Mon, 30 Sep 2019 15:26:45 GMT

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:

devzone.nordicsemi.com/.../8203.0001_2D00_Drop_2D00_events_2D00_for_2D00_invalid_2D00_connection_2D00_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?

RE: SDK14.1 Multilink with NUS data sent issue

WET TF — Sat, 24 Mar 2018 21:30:30 GMT

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.

RE: SDK14.1 Multilink with NUS data sent issue

Sigurd — Fri, 23 Mar 2018 13:40:09 GMT

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.

RE: SDK14.1 Multilink with NUS data sent issue

WET TF — Fri, 23 Mar 2018 00:02:54 GMT

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.