Zephyr BLE connection management

RE: Zephyr BLE connection management

Amanda Hsieh — Thu, 26 Jan 2023 16:36:56 GMT

Hi,

There are some APIs that are documented as giving you a reference. And the application needs to unref this when they don't use it anymore like this, this and this.

 *  The caller gets a new reference to the connection object which must be
 *  released with bt_conn_unref() once done using the object.

Neither the connected-callback invocation nor the disconnected-callback invocation comes with an ownership transfer of a bt_conn reference. (When a API does, it has to be documented in the API doc.) Any call to bt_conn_unref in disconnected() presumably gets rid of ownership acquired earlier from some other source.

[quote user="owain"]See here attached a trace where bt_conn_unref() is called on disconnect(); this results in an assertion that related to refrence counters.[/quote]

Do you use bt_conn_ref or the function would increase the counter? If not, then it doesn't need to call bt_conn_unref. I would correct my previous answer.

-Amanda H.

RE: Zephyr BLE connection management

OwainIncus — Mon, 23 Jan 2023 11:58:50 GMT

In fact if I search through all sample code; one sees most examples using bt_conn_unref(); but only some that have calls to bt_conn_ref().

RE: Zephyr BLE connection management

OwainIncus — Mon, 23 Jan 2023 10:37:26 GMT

Hi Amanda,

So in the connected() callback we are given the reference to the connection (A reference counter has been incremented in the stack somewhere?).

And in the disconnected() callback I must explicitly call bt_conn_unref()? this is not very symmetrical. Counter incremented inside the stack but decremented outside the stack. Where is that reference counter incremented?

Its funny because at the moment the bt_conn_unref() is commented out in my disconnect routine before disconnect routine calls bt_conn_le_create_auto() and the device is merrily disconnecting/reconnecting as peripheral RF connection is blocked/freed using a faraday bag.

See here attached a trace where bt_conn_unref() is called on disconnect(); this results in an assertion that related to refrence counters.

Regards,

Owain

devzone.nordicsemi.com/.../blePeripheralRefCounter.txt

RE: Zephyr BLE connection management

Amanda Hsieh — Fri, 20 Jan 2023 17:35:51 GMT

Hi,

1. The flow looks correct. Security and service discovery should be executed on each connection.

2. bt_conn_unref would decrement a connection’s reference count. It is used when the connection counter involved the application.

Regards,
Amanda H.

RE: Zephyr BLE connection management

OwainIncus — Fri, 20 Jan 2023 16:18:45 GMT

This looks to be to do with the connection reference counters.
If I remove the bt_conn_unref() from the disconnect() callback and just re'arm the wit for incoming connection with bt_conn_le_create_auto(); then I can merrily loose and regain the sensor at random and the connection is reconnected after each period of disconnect.

So only if it is a deliberately disconnect a peripherl should one do a bt_conn_unref()?

This may be answer to one of my initial questions.

RE: Zephyr BLE connection management

OwainIncus — Fri, 20 Jan 2023 10:59:59 GMT

Hi Hung,

Any hints here?
Unfortunately samples don't go into this detail.

Regards,
Owain