BLE_GAP_EVT_DISCONNECTED doesn't occur when connection is terminated after receiving LL_VERSION_IND

[Remo]

Hi

We established a connection with a mobie phone as central device and an nRF52832 or nRF52833 as peripheral device.
If we afterwards try to terminate the connection on the nRF with sd_ble_gap_disconnect(), the BLE_GAP_EVT_DISCONNECTED does not occur.

We have seen with a Bluetooth sniffer, that the SoftDevice sends the LL_TERMINATE_IND right after the central device has sent the LL_VERSION_IND.
Is it possible that the SoftDevice could not trigger BLE_GAP_EVT_DISCONNECTED because it is somehow stuck because it could not answer the LL_VERSION_IND?

If we add a small delay so that the connection is terminated after the SoftDevice answered the LL_VERSION_IND, the BLE_GAP_EVT_DISCONNECTED is triggered.

The problem occurred on the nRF52832 (S132 V7.2.0) and on the nRF52833 (S140 V7.2.0).

Do you know this behavior?

Many thanks in advance.
Remo

[Einar Thorsrud]

Hi Remo,

This is a known bug. It is fixed in version 7.3.0.

[Remo]

Hi Einar

Thank you for your answer.

I just replaced the SoftDevice 7.2.0 with 7.3.0 (without making any changes on our FW), but the problem still occurs.

Is it possible that this issue is not the same as DRGN-15619? Do you have an idea what else I can try?

[Remo]

Hi Einar

No, I didn't mix up the disconnected reasons. I received 0x22 in the error case and 0x16 in the good case.

We are using the Frontline Sodera BLE sniffer. Are you able to open these trace files? I made here a screenshot of the last packages of the trace from the Sodera:

I looked into the sniffer trace you sent. When I see it correctly, there are two empty PDU's between the LL_VERSION_IND of the mobile and the LL_TERMINATE_IND of the nRF52832. Can you adjust the timing so that there are no empty PDU's between the mentioned LL packets? I think that this should reproduce the problem.

Best regards

[Einar Thorsrud]

Hi Remo,

I have discussed this with our SoftDevice team, and due to some implementation details in the SoftDevice, it is expected that you do not get the immediate disconnect with BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION in this specific case, where the nRF sends the LL_TERMINATE_IND in the same connection event as it received LL_VERSION_IND. You will always get a disconnected event with a timeout reason later though, so it is not a critical issue, but the SoftDevice could have handled this more gracefully.

Br,

Einar

[Remo]

Hi Einar

Thank you for the explanation. Do you know if this implemantation detail will be fixed if there will be a new SoftDevice release?

Best regards

[Einar Thorsrud]

I cannot say for sure it it will be included in a new release or not, but generally you should not expect large updates to the SoftDevices going forward (due to most new activity happening with the nRF Connect SDK). Also, the disconnected event only happens after the peer has acknowledged the LL_TERMINATE_IND, and if this does not happen for instance due to the ACK being lost on air, you will also have to wait for the timeout, so you anyway need to handel that condition.

[Remo]

Ok, thank you.