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 ?

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.

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.