Central device claims to have Connected but no Connection event is fired on the peripheral

[nvelozsavino]

I'm developing a multirole device to connect to a peripheral device that we developed earlier.

The multirole device when acting as a central device it scans for the peripheral and if found it connects, then secure the connection and bond. After several successful connections, the central says that it connects to the peripheral but before being able to secure the connection or to discovery the services it disconnects.

I've enabled the logger on both devices and added logs to see the progress of the connection and the events.

I've seen that when the problem happens, the central is showing me the BLE_GAP_EVT_CONNECTED but the peripheral doesn't show anything. it's like the central device is firing a false BLE_GAP_EVT_CONNECTED event.

I've tried with the scan_params.extended on and off and the behavior is the same.

I've confirmed that when connected from another central that works fine (using the phone with the nrfConnect application), the peripheral shows the events as expected.

Both devices are using the nrf52832

The peripheral is using the SDK 15.0.0 and the softdevice s132 6.0.0

The device acting as a central is using the SDK 16.0.0 and the softdevice s132 7.0.1

[nvelozsavino]

Hello Keneth, yes, I'm using a whitelist on the peripheral, however, that's not the problem, there's no other central trying connecting, and if that would be the case, disabling the whitelist on the peripheral would allow the old central to connect again, however, even disabling the whitelist on the peripheral doesn't work unles I delete all bonds on the central device.

I've already tested the allowing repair, that's not the issue, the code doesn't even reach the event PM_EVT_CONN_SEC_CONFIG_REQ on the peripheral. before getting to that point it requires to fire at least BLE_GAP_EVT_CONNECTED or PM_EVT_BONDED_PEER_CONNECTED, whitch doesn't occour. It's like the connection request is not going out over the air, or the peripheral filter it somehow, is there a way to debug the Softdevice sd_ble_gap_connect step by step?

[Kenneth]

I think the next step for debugging is to try download and use the nRF sniffer, so we may see if the connection request packet is indeed sent or not:

https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE 

On the peripheral you may also monitor the whitelist, to see if it's updated at any time during, before or after advertisement/connection.

[nvelozsavino]

I finally was able to get the sniffer traces, I can't see any connection response from the peripheral, however, the master still tries to negotiate the MTU

traces_with_issue.pcapng

The peripheral address is: e6:9d:93:ce:2d:c0

and the master address is: e1:2e:95:29:49:6c

[Kenneth]

Everything is pointing to the connection request packet is not received (the advertisement timing indicate that the interval is not stopped at any time). The MTU exchange is just the first packet from the central, so that doesn't contradict that the connection request packet is not received.

Presuming that whitelist is not enabled on the peripheral, then the only other explanation is some noise preventing the connection request packet to be received on the peripheral. Is the peripheral here an nRF52-DK or your own hardware? Is there any serial interfaces active near the antenna that may prevent the packet from being received?

Best regards,
Kenneth

[nvelozsavino]

The MTU exchange shouldn't wait for the connection response?

The whitelist is enabled on the peripheral, but the central is a known device and it's within the whitelist of the peripheral

The peripheral is our own hardware, It's working just fine with other central using other softdevice s132 6.0.0

I doubt it has something to do with signal interference, the problem seems to be related with the flash storage on the central, because as soon as you do a mass erase on the central and disable the whitelist on the peripheral to allow the bond to be updated, it connects again. All this without changing anything in the environment.

Before you ask, I've already tried disabling the whitelist on the peripheral, The peripheral doesn't even know there's a connection request.

I've noticed that the problem happens when the central has more than one device in the whitelist,