This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Second connection setup to wrong peer by central.

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

  • Hi

    Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause.

    v5.1.0 of SoftDevice S132 is the only SoftDevice that is production tested (and thus officially supported) with the nRF52810. It generally isn't a good fit for a central application exactly because of its restrictions in terms of RAM and Flash memory. If possible, I would suggest moving the project to a device with more memory.

    What is this peripheral that you're connecting to twice? Is this an nRF52 device as well or some other device? Are these two peripheral devices similar or distinctly different in terms of advertisement packets, device names, what services they provide, and so on? I've not heard of something like this before, so I'll need to do some investigation before getting back to you.

    Best regards,

    Simon

  • One additional piece of information: when the central connects to the wrong device we get the following log output:

    sd_ble_gatts_exchange_mtu_reply() returned unexpected value 0x8.

    Our current solution is to detect that we are connected to the wrong peripheral and in that case disconnect and try again. Sometimes it fails many times before succeeding.

    The peripheral is an nrf52 that uses sdk 15.2 and softdevice 6.1. Even though it also a product developed by us we cannot change that firmware as it is already in production and probably sold to end users.

    I use our own service id that is advertised in a advertising response packet and based on that we decide to connect.

  • 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

Related