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

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