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.

[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]

[Kenneth]

Rifatansz said:

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

According to BLE spec:

Have in mind that the connection request packet is a rather large packet, and if there is any error during this packet, then it will not be received by the peripheral that is advertising. In such case by BT spec the central should stop after 6 attempts.

Everything here looks to be perfectly normal, I must admit that 20% was a large numbers, so the only thing I would like to add is that you should have someone to review your design if you haven't already, and in specific run the radio test example with constant carrier and measure the frequency accuracy of the carrier using a spectrum analyzer. The carrier frequency should be maximum +-96kHz off the center frequency, e.g. 2402MHz+-96kHz. Also for test the 32kHz can be configured with 500ppm tolerance setting in case it's out of specification, if possible use the internal 32kHz RC for comparison.

Kenneth

[Rifatansz]

Thank you for your detailed explanation. You're right — the connection request packet is large, and that could definitely contribute to the issue.

After further investigation, I’ve found that when fewer GATT services are enabled, the connection becomes stable. Specifically, I am using the following services:

CONFIG_SNS_SERVICE_ENABLED=y CONFIG_ECG_SERVICE_ENABLED=y CONFIG_PPG_SERVICE_ENABLED=y CONFIG_MOT_SERVICE_ENABLED=y CONFIG_COM_SERVICE_ENABLED=y

When only two of these services are enabled, the central device can consistently connect without issues. However, when all of them are active, the likelihood of the peripheral not responding with LL_FEATURE_RSP during connection increases significantly — up to around 20% failure rate.

What kind of improvements would you suggest to maintain a stable connection while keeping these services enabled? These services are essential to my application, so I’m looking for ways to optimize performance without reducing functionality.

[Rifatansz]

We are using the u-blox NORA-B100 module. Do you have any guidance on how we can perform the test you mentioned?

Additionally, you mentioned that the packet size may have an effect during connection. Could you please clarify what the contents of the connection request packet are, and how we might be able to reduce its size, if possible?

[Rifatansz]

I’ve tried optimizing advertisement parameters, service structure, and delayed MTU exchange, but the issue still persists.

Do you have any official recommendations or best practices to handle large GATT tables during BLE connection establishment on nRF5340 series (or SDK 2.6.1)?