Managing Multiple BLE Connections on nRF5340DK (NCS 2.9.1)

[bubune]

Hi,

I’m using an nRF5340DK with nRF Connect SDK 2.9.1, configured as both Central and Peripheral with the nordic SDC running the network processor 
Goal: allow the board to connect to two Central devices simultaneously, with a maximum of three connections allowed.
The first device has a fixed MAC address and a dedicated slot in my connection table.

---

Issue:

1. Lost connection with the second Central (MAC address not fixed)
   Two scenarios occur:

   • Case 1: The nRF5340DK detects the disconnection (reason 8 - timeout), releases resources → the Central reconnects successfully.

   • Case 2: The nRF5340DK does not detect the disconnection.
     The Central initiates a new connection, which occupies the third slot.
     Since I only allow two active connections, I forcefully disconnect the old connection using:

     bt_conn_disconnect(conn2, BT_HCI_ERR_REMOTE_USER_TERM_CONN);

     bt_conn_unref(conn2);

     Afficher plus de lignes

     Then I register the new connection in the second slot.
     Problem: the resources for the old connection are never released.

---

2. HCI error after 3 connections
   When three Centrals are connected, I get this error right after the connected callback:

   bt_hci_core: opcode 0x2039 status 0x0d
   

   The connection still works and data is exchanged, but the nRF5340DK is no longer discoverable (all 3 slots are occupied, including 1 that should have been freed).
   If a Central disappears again without being detected, it cannot reconnect.

---

Questions:

• What is the proper way to completely remove a BLE connection?
  bt_conn_unref() doesn’t seem to be enough.
• How can I resolve the error:

  bt_hci_core: opcode 0x2039 status 0x0d
  

a part of  my app prj.conf 

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_CENTRAL=y

CONFIG_BT_DEVICE_NAME="test"

CONFIG_BT_DEVICE_APPEARANCE=832

CONFIG_BT_MAX_CONN=6

CONFIG_BT_MAX_PAIRED=6

CONFIG_BT_BUF_ACL_RX_COUNT=16

CONFIG_BT_EXT_ADV=y

CONFIG_BT_SMP=y

CONFIG_BT_SCAN=y

CONFIG_BT_SCAN_FILTER_ENABLE=y

CONFIG_BT_SCAN_ADDRESS_CNT=2

CONFIG_BT_GATT_NOTIFY_MULTIPLE=y

CONFIG_BT_GATT_CLIENT=y

CONFIG_BT_GATT_DM=y

CONFIG_BT_RX_STACK_SIZE=4096

CONFIG_HEAP_MEM_POOL_SIZE=8192

CONFIG_MAIN_STACK_SIZE=4096

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

 prj.conf (network):

CONFIG_BT_EXT_ADV=y

CONFIG_BT_CTLR_ADV_EXT=y

CONFIG_BT_PER_ADV=y

CONFIG_HEAP_MEM_POOL_SIZE=8192

CONFIG_MAIN_STACK_SIZE=2048

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

CONFIG_IPC_SERVICE=y

CONFIG_BT=y

CONFIG_BT_HCI_RAW=y

CONFIG_BT_MAX_CONN=6

CONFIG_BT_CTLR_SDC_PERIPHERAL_COUNT=3

CONFIG_IPC_RADIO_BT=y

CONFIG_IPC_RADIO_BT_HCI_IPC=y

Thanks for your help!

[Edvin]

Hello,

Sorry for the late reply.

releases resources → the Central reconnects successfully

What exactly do you mean by "releases resources"?

When doing this testing for case 1 and 2. How do you do this physically? Do you reset the centrals?

If that is the case, you may see that the central actually reconnects before the connection, as seen from the peripheral has timed out yet. The central, who just woke up from a reset is not aware of the previous connection (which has not yet disconnected), and from the peripheral, this looks like a second connection to the same device. 

If that is in fact the case, you can add a small delay before the central starts scanning. Make it equal to the disconnect supervision timeout value, to make sure that all it's previous connections have timed out before it tries to reconnect. 

Whether this is actually needed is up to you. How often will devices be reset out in the field, where this is not caused by a power on reset (because it ran out of battery)? 

Or are you seeing something completely different?

Best regards,

Edvin