nRF5340 LE disconnection Issue.

[AKV]

Hi,

We are using nRF5340 DK and the nRF Connect SDK Version 2.6.1.

We are experiencing an issue with disconnections. We use bt_conn_ref() when receiving the connected event and bt_conn_unref() when receiving the disconnection event.

However, sometimes after a disconnection, when we retry, we encounter the error: "bt_conn: bt_conn_exists_le: Found valid connection (0x20001a18) with address FF:F5:55:5A:D6:6A (random) in disconnected state".

Why does this issue occur even after the disconnection event has been processed?

If we call bt_conn_unref() twice during the disconnection event as shown in the below code (essentially incrementing once upon connection and decrementing twice upon disconnection), the issue does not occur.

void connected(struct bt_conn *conn, uint8_t conn_err){
	bt_conn_ref(conn);
}
void disconnected(struct bt_conn *conn, uint8_t reason){
 	bt_conn_unref(conn);
 	bt_conn_unref(conn);	
}

Could this behavior be due to an internal counter issue?

[Vidar Berg]

Hi,

I'm not aware of any known issues where the Bluetooth host fails to release its own reference. Are you developing a peripheral or central application?

Thanks,

Vidar

[AKV]

Hi, 

Thanks for the response.

We are developing a mesh network. Our requirement is the one device can connect to three other devices. Using one connection as a peripheral and up to two connections as a central for mesh connections.

[Vidar Berg]

Hi,

For the GAP central role, you should decrement the reference count in the connectected callback if the connection failed to be established: https://github.com/nrfconnect/sdk-nrf/blob/57e64dd9671a27f6d78172d5526cbedcbbebcc70/samples/bluetooth/central_and_peripheral_hr/src/main.c#L233. Clients need the connection object for performing service discovery. For the peripheral/server, it is often not necessary to increment the reference count.

[AKV]

Hi

Thanks for the response.

I followed the example implementation you suggested, but the issue persists. 

[dejans]

Hi,

Could you provide a complete log showing the error?

Best regards,
Dejan

[AKV]

Hi,

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***

[00:00:00.017,944] <inf> bt_hci_core: hci_vs_init: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.017,944] <inf> bt_hci_core: hci_vs_init: HW Variant: nRF53x (0x0003)
[00:00:00.017,974] <inf> bt_hci_core: hci_vs_init: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
[00:00:00.019,805] <inf> bt_hci_core: bt_dev_show_info: Identity: FF:F5:55:5A:D6:6A (random)
[00:00:00.019,836] <inf> bt_hci_core: bt_dev_show_info: HCI: version 5.4 (0x0d) revision 0x218f, manufacturer 0x0059
[00:00:00.019,836] <inf> bt_hci_core: bt_dev_show_info: LMP: version 5.4 (0x0d) subver 0x218f

[DISCOVERY]: Discovery Mode Fast Scanning
[DISCOVERY]: Discovery Mode Fast Advertising

[CONN]: Connecting to Node:34628, DeviceAddress:D9:55:D0:0F:78:7D (random)
[CONN]: ####### CONNECTED as CENTRAL  MacAddr:D9:55:D0:0F:78:7D (random) #######
[CONN]: CONN_COUNT:1, ConnDataIndex:0, conn_handle:0, k_uptime_get_32():2745
[DISCOVERY]: Discovery Mode Slow Scanning
[CONN]: MTU exchange done

èONN]: ####### CONNECTED as PERIPHERAL,  MacAddr:FA:8F:B8:34:60:23 (random) #######
[CONN]: CONN_COUNT:2, ConnDataIndex:1, conn_handle:9, k_uptime_get_32():6873
[DISCOVERY]: Discovery Mode Slow Scanning

[CONN]: Force disconnecting Node:34628, conn->handle:0
[CONN]: ####### DISCONNECTED Reason: 22  MacAddr:D9:55:D0:0F:78:7D (random) #######
[CONN]: CONN_COUNT:1, conn_handle:0, conn->state:0, k_uptime_get_32():6977

[RECONN]:Reconnection Nodeid:34628, Addr:D9:55:D0:0F:78:7D (random)
[CONN]: Connecting to Node:34628, DeviceAddress:D9:55:D0:0F:78:7D (random)
[00:00:06.980,743] <wrn> bt_conn: bt_conn_exists_le: Found valid connection (0x20001aa0) with address D9:55:D0:0F:78:7D (random) in disconnected state
[ERROR]: Create conn failed (err -22)

In the provided logs, you can observe the connection and disconnection sequences.

Initially, I connected to the device with the address D9:55:D0:0F:78:7D as a master. Then, I connected to the device with the address FA:8F:B8:34:60:23 as a peripheral.

Afterward, I disconnected the first device, D9:55:D0:0F:78:7D, and received a disconnection event indicating that the state is disconnected.

However, when I attempted to reconnect to the last disconnected device, an error occurred stating, "Found valid connection (0x20001aa0) with address D9:55:D0:0F:78:7D (random) in disconnected state."

[Vidar Berg]

AKV said:

However, when I attempted to reconnect to the last disconnected device, an error occurred stating, "Found valid connection (0x20001aa0) with address D9:55:D0:0F:78:7D (random) in disconnected state."

Where does your application attempt to reconnect, is it within the disconnected callback, or right after?

[AKV]

Hi,

Thanks for the response.

I was retrying the disconnected callback. Now, I've added a flag to the disconnect callback, I will check the disconnect flag and initiate the connection from a separate thread, rather than reconnecting from the disconnect callback.

This approach has significantly reduced the failure rate, but occasionally the error "Found valid connection (0x20001aa0) with address D9:55:D0:0F:78:7D (random) in disconnected state" still occurs.

I've observed that there are occasional connectivity issues as well,

1. Failed to connect to D9:55:D0:0F:78:7D (random) with ERROR (2).

2. Post connection the issue "MTU exchange failed (err 14)" occurs and then disconnect.

[Vidar Berg]

Hi,

Rather than triggering the re-connect from a separate thread, please try to do it from the system workqueue. This should help ensure that the processing of the disconnect event in the BT host is completed before the connection is initated again. Here is an example of how you can define a workqueue item: https://github.com/nrfconnect/sdk-nrf/blob/8765c758005e4e65d40dafd9d2f2d4a2be5639fa/samples/bluetooth/peripheral_hr_coded/src/main.c#L38 

AKV said:

I've observed that there are occasional connectivity issues as well,

1. Failed to connect to D9:55:D0:0F:78:7D (random) with ERROR (2).

2. Post connection the issue "MTU exchange failed (err 14)" occurs and then disconnect.

The error could indicate that the bt_conn_le_create() timed out. Are you calling bt_conn_le_create() instead of scan_start() when receiving the disconnect event?

The MTU exchange should not be initiated if there was a connection error.