Second connection setup to wrong peer by central.

[Bert Thomas]

Hi all,

We run into a problem where our central product (a remote control) connects to the wrong device. We are using SDK v14.2.0 and softdevice S132 version 5.1.0. At the start of the project we tried using the then most current SDK and softdevice but we are using nRF52810 and the then current softdevice simply uses so much flash that hardly any is left for the application. That's why we decided to switch to the first SDK and softdevice versions that supports a central on a nRF52810,. (The reason for picking a nRF52810 instead of one of the larger ones has to do with availability)

I used the ble_app_blinky_c example as starting point and further down the line adapted it to support multiple connections and secure connections. One of the first symptoms I noticed was that the same peripheral was connecting twice to the central, even though the central explicitly detects MAC addresses it is already connected to and ignores advertising reports from those. Investigating let to the point where as soon as the connection was set up the peer manager sometimes reports a wrong peer id in the pm events, even for the first connection. I blamed the peer manager for that so adapted my program to not rely on the peer id reported by pm events. This did not solve our problem, so I added code to log the mac address provided by the BLE_GAP_EVT_CONNECTED:

case BLE_GAP_EVT_CONNECTED:
{
NRF_LOG_INFO("Connected.h=%d addr %02x %02x %02x",
p_gap_evt->conn_handle,
p_gap_evt->params.connected.peer_addr.addr[0],
p_gap_evt->params.connected.peer_addr.addr[1],
p_gap_evt->params.connected.peer_addr.addr[2]);

This resulted in the observation that the address printed here is not the same as the address that sd_ble_gap_connect() used. Any idea why this happens?

Some more background information: we have two peripherals that are both whitelisted on the central. When only one peripheral is on when the central awakes, everything is just fine. However, when both peripherals are on it sometimes behaves as expected and sometimes it connects to the wrong peripheral, sometimes even to the one it is already connected to.

- Bert

[Simonr]

Hi

The sd_ble_gatts_exchange_mtu_reply() indicates that the device is in an "invalid state" when trying to send this reply. Is the sd_ble_gatts_exchange_mtu_reply() function being called elsewhere in your project outside of the GATT module? One reason you may get the invalid state error is if the application responds to the same MTU REQUEST event multiple times for instance. You should only define one GATT instance, as this instance will handle both central and peripheral connections.

Best regards,

Simon