Peripheral missing disconnect on timeout

Hi,

Did you register a disconnected callback? E.g. as shown here?

When debugging I notice that disconnect does not work as it returns that it is not connected, but conn->ref is not 0. Calling unref till it reaches 0 causes it to start advertising again.

But upon trying to connect to this we get
***New connection: 0 (printed by on_gap_evt_connected in our script)
connect_to_device error: 'NoneType' object is not subscriptable.

After this, it stops advertising again while state remains in BT_CONN_CONNECT_ADV.

Looks like, when the error happens, ref is still 3.
Normally ref is 2, and upon disconnect we unref the local pointer to the connection and it returns to 1, and advertising is resumed. Are we using the bt_conn_ref() correctly?

Hi,

Kyrre Aalerud said:

when the error happens, ref is still 3.
Normally ref is 2,

That sounds strange. Where are the places you call bt_conn_ref() and bt_conn_unref() ? In what callbacks?

Could you post the code relevant functions / callbacks where you call bt_conn_ref/bt_conn_unref ?

Hi,

Kyrre Aalerud said:

when the error happens, ref is still 3.
Normally ref is 2,

That sounds strange. Where are the places you call bt_conn_ref() and bt_conn_unref() ? In what callbacks?

Could you post the code relevant functions / callbacks where you call bt_conn_ref/bt_conn_unref ?

The ref:

static void connected(struct bt_conn *conn, uint8_t err)
{
    struct bt_conn_info info;

    if (err) 
    {
        LOG_ERR("BLE Connection failed (err 0x%02x)", err);
        return;
    }

    default_conn_ble = bt_conn_ref(conn);

    bt_conn_get_info(conn, &info);
    LOG_INF("BLE Connected: Interval=%d, Datalen=%d", info.le.interval, info.le.data_len->tx_max_len);

The connected() callback goes on to check some parameters and request changes in data length if appropriate.

The unref:

static void disconnected(struct bt_conn *conn, uint8_t reason)
{
    LOG_WRN("BLE Disconnected (reason 0x%02x)", reason);
    if (auth_conn) 
    {
        bt_conn_unref(auth_conn);
        auth_conn = NULL;
    }
    
    if (default_conn_ble) 
    {
        bt_conn_unref(default_conn_ble);
        default_conn_ble = NULL;
        disable_reporting_over_ble(); // Once disconnected, disable reporting over BLE
    }
}

We only support one connection, and it appears the issue happens more if we trigger two quick connects from same unit in python with connectivity dongle before previous connect has finished or failed. This seems to queue up two connections in such a way as to leave us out of sync and closing/reopening python sript (and device) seems to cause the connection to close so we can continue.

Has there been any progress on this? We manage to reproduce the hang regularly but are unable to figure out why it happens. Any failed transmit on NUS is handled.

Hi,

I have tried to reproduce the issue, but so far it's working fine here.

Are you able to provide a simple pc-ble-driver python script, together with a simple nRF Connect SDK sample that reproduces this?

So far it has been difficult to strip it down to a working example.
The basic premise is apparently starting new connections while already starting a connection from the python side in such a way as to get the dongle in a "busy" state. When reset later it sometimes gets the peripheral in an odd state where it doesn't disconnect properly?

Maybe we can share project access, but it would be some work to make it run without the external hardware that is integrated into the code. In theory a blank NUS example with some high traffic should be all it takes while trying to "pester" it with connections, but the sample does not build for me and I did not have time to dig into it.