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

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

Remo — Thu, 11 May 2023 14:07:49 GMT

Ok, thank you.

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

Einar Thorsrud — Thu, 11 May 2023 11:55:26 GMT

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.

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

Remo — Thu, 11 May 2023 09:30:22 GMT

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

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

Einar Thorsrud — Thu, 11 May 2023 07:25:35 GMT

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

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

Remo — Tue, 09 May 2023 15:47:53 GMT

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

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

Einar Thorsrud — Tue, 09 May 2023 07:20:14 GMT

Hi,

I have not been able to reproduce this on my end yet. I ended up with a slightly more modified ble_app_hrs example, testing on the nRF52 DK (nRF52832) and SDK 17.1.0, but with S132 7.3.0.The changes are mostly your modified main.c file, but I modified it slightly. For reference, the slightly modified main.c and sdk_config.h (where the change there is to use default data length and ATT MTU) are attached together with the sniffer trace: devzone.nordicsemi.com/.../nrf_5F00_connect_5F00_iphone_5F00_trace.pcapng.

main.c:

devzone.nordicsemi.com/.../64850.main.c

sdk_config.h:

devzone.nordicsemi.com/.../76725.sdk_5F00_config.h

In the log I get this:

...
<info> app: Disconnected, reason 22 (0x16).
...

As BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT is 0x22 and BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION is 0x16 which is 22 decimal, this makes me wonder if it could be that you accidentally mixed up decimal and hex? You should anyway get the disconnect event immediately though, but I want to double check.

Can you share a full sniffer trace showing all packets for a complete connection (starting and ending with the peripheral advertising)? Perhaps with that it will be easier to see which exact conditions need to be present in order to reproduce the issue.

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

Einar Thorsrud — Mon, 08 May 2023 12:40:07 GMT

Hi Remo,

Yes, you are right. You should get the disconnected event right away (and not as a supervision timeout). I need to look a bit more into this but will get back to you.

Einar

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

Remo — Fri, 05 May 2023 09:52:20 GMT

Hi Einar

Thank you. I expect that the BLE_GAP_EVT_DISCONNECTED event occurs right away when the link has been terminated and not after 5 seconds when the supervision timeout expired.

I don't check the disconnect reason in my application. This was just an observation during reproducing the issue.

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

Einar Thorsrud — Fri, 05 May 2023 09:29:39 GMT

Hi Remo,

Thank you, I will test this on my end. Just on question first so there are no misunderstandings: Is it so that you always get the BLE_GAP_EVT_DISCONNECTED event after all, just that you do not get the disconnect reason you expected?

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

Remo — Fri, 05 May 2023 06:42:30 GMT

Hi Einar

Sorry for the late response. I needed some time to reproduce this behavior with the example "ble_peripheral\ble_app_hrs" from the nRF5 SDK V17.1.0 with S132 V7.3.0.

While trying to reproduce it, I realized that the disconnected-event is not lost in the error-case (as I thought in the first place), but it occurs first after the supervision timeout has expired (after 5s in my case) with the reason 0x22 BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT. In the good case, the event occurs right away with the reason 0x16 BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION.

Please see below the attached modified main.c from the example ble_app_hrs which showed also the described issue. The importent part starts on line 705. There, I have added two different delays to show the good and the bad case. Important is that the delay for the bad case needs to be adjusted so that the LL_TERMINATE_IND is sent as "reply" to LL_VERSION_IND for the mobile you're using.

devzone.nordicsemi.com/.../main_5F00_mod_5F00_for_5F00_Nordic.c

Best regards
Remo

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

Einar Thorsrud — Wed, 03 May 2023 08:19:28 GMT

Hi Remo,

I am not aware of any other known issues that would cause the disconnected event to be lost. You may loose some events (like advertising reports), but critical events like this is prioritized and will not be intentionally dropped. There may be some bug we are not aware of, though.

How do you handle the SoftDevice events in your application? Could there be an issue there? Are you able to share some code that can reproduce this on a DK?

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

Remo — Tue, 02 May 2023 06:35:21 GMT

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?

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

Einar Thorsrud — Fri, 28 Apr 2023 12:10:03 GMT

Hi Remo,

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