BLE Connection Issue with nRF5340 Device

[Rifatansz]

Hello,

I am using the nRF5340 in my project, and the device is capable of communicating with a mobile phone over BLE. However, we occasionally encounter a connection error when trying to connect to the device from our mobile application.

I captured the issue using Wireshark, and the device address at the time was E4:E6:0F:05:AF:C0. The device had sufficient battery and was in close proximity to the phone during the test. Despite this, the connection attempt fails intermittently.

Unfortunately, I couldn’t identify the root cause of the problem from the Wireshark logs. Could you please help me understand what might be causing this connection issue?

Thank you in advance.

e4_e6_0f_05_af_c0 connection error.pcapng

[Kenneth]

Hello,

If you experience repeated BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reasons, it may be that the peripheral device have whitelist enabled while advertising, whitelist on the peripheral device only allow previously bonded central devices to connect with the peripheral. You may need to enable pairing on the peripheral device to allow a new central device to connect and bond in this case.

What may cause intermittent BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reason:

In a realistic end-user environment there are a lot of 2.4GHz traffic, it can be traffic from other Bluetooth devices communicating, it can be Bluetooth devices that are trying to scan or connect to the same peripheral device, it can be Wifi devices that typically have higher output power and use much higher bandwidth, other proprietary 2.4GHz equipment (even microwave ovens or USB3.0 noise). All this 2.4GHz traffic will interfere, and sometimes this interference will cause packets to not be received by the peer device. This is very normal in a wireless application. It's very difficult to estimate the amount of packet that can be lost, since it depends so much on the environment, but typically you will expect about 1-5% of the packets to be lost. This will mean that about 1-5% of the times you try to establish a connection you will experience a BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED on the central. How should you handle this? My suggestion is simply to try to connect again.

Kenneth

[Rifatansz]

Hi Kenneth,

Yes, we are experiencing intermittent connection failures with our device. However, in the Wireshark capture I previously shared with you, I was not able to directly identify the BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED error.

I’m curious how you determined that this specific error occurred based on the log. I reviewed the packets but couldn’t find a clear indication of that particular HCI error code.

In the shared capture, the device attempts to connect to the mobile application, but a failure occurs during the process. However, I wasn't able to interpret the technical details that point to the cause of the failure.

Could you please clarify if this specific error is present in the capture, and if so, which packet or message indicates it? Your feedback would help us better understand how to analyze similar issues moving forward.

Thank you very much for your support.

[Kenneth]

Hi,

A valid question, it's not visible in the air log no, and unfortunately I don't expect the phone will show this disconnect reason either (they do not expose it).

Kenneth

[Rifatansz]

Thank you for your response.

In some of my other projects, I’ve also used Wireshark to analyze BLE connections. In those cases, I was usually able to infer the reason for disconnection — such as timeouts or missing responses — from the captured packets.

Even if the exact error code is not available, shouldn’t it still be possible to detect that a connection failure occurred during the connection process itself? I was expecting to see at least some indication of the failure in the log.

[Kenneth]

If you choose sniffing a connection involving a single peripheral:
https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/common_actions_sniffing_conn_single_periph.html

Then you should see the central send 6 packets before giving up if the disconnect is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

Kenneth

[Rifatansz]

I'm working with the nRF5340 and using the nRF Connect SDK version 2.6.1. My device is configured as a Bluetooth Low Energy Peripheral, and I’m using the SoftDevice Controller (CONFIG_BT_LL_SOFTDEVICE=y) for the link layer.

While analyzing BLE packets using a sniffer during a connection initiated by a Central device (a PC), I noticed the following:

The Central sends an LL_FEATURE_REQ packet during the connection setup phase.

However, my Peripheral device sometimes does not respond with an LL_FEATURE_RSP.

This behavior is not consistent — in some connections the response is sent as expected, but in others it is completely missing, even though the connection is successfully established.

I added a delay (k_sleep(K_MSEC(300))) after connection to avoid timing issues, but the problem still persists.

Sniffer logs confirm that the Central retries LL_FEATURE_REQ in some cases, suggesting that the initial LL_FEATURE_RSP was never received.

I also verified that CONFIG_BT_CTLR_FEATURE_EXCHANGE=y is enabled. Furthermore, enabling debug logs did not reveal any errors or useful indicators at the application level.

My questions are:

Under what conditions might the SoftDevice Controller intentionally skip responding to an LL_FEATURE_REQ packet?

Is there a workaround or recommended way to ensure the controller reliably responds to LL_FEATURE_REQ?

I'd be happy to provide sniffer traces, prj.conf, or any other logs if needed.

This issue does not occur consistently, but based on repeated testing, the missing LL_FEATURE_RSP response occurs in approximately 20% of connection attempts.

[Rifatansz]