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]

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

[Kenneth]

Hi,

One thing you should do in any case is to update to nRF Connect SDK v2.6.4, this will then include some fixes in general that may be relevant. Can you build to get some debug information?

Normally you can get more information about a fault by adding something like:

CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y

# Debugging configuration
CONFIG_THREAD_NAME=y
CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
CONFIG_THREAD_ANALYZER_USE_PRINTK=y

# add asserts
CONFIG_ASSERT=y
CONFIG_ASSERT_VERBOSE=y
CONFIG_ASSERT_NO_COND_INFO=n
CONFIG_ASSERT_NO_MSG_INFO=n
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_NAME=y

Kenneth

[Rifatansz]

I have updated to nRF Connect SDK v2.6.4 as recommended. However, after the update, I noticed a significant increase in power consumption. While my device was previously consuming around 500 µA with SDK v2.6.1, it now draws approximately 4.5 mA.

Additionally, I disabled the serial in the rpmsg file (set CONFIG_SERIAL=n). Despite the higher current draw, the device is running, and the BLE functionality is working. However, I am still experiencing BLE connection issues.

I'll share my current prj.conf file below for your review and would appreciate any support in identifying the cause of the increased power consumption and ongoing connection issues.

# Enable Bootloader 
CONFIG_BOOTLOADER_MCUBOOT=y
# Enable APP CORE DFU -- Disable for multicore DFU
# CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

# Enable SMP Server
CONFIG_MCUMGR=y
CONFIG_MCUMGR_GRP_IMG=y

# CONFIG_MCUMGR_GRP_IMG dependencies
CONFIG_FLASH=y
CONFIG_IMG_MANAGER=y

# CONFIG_IMG_MANAGER dependencies
CONFIG_STREAM_FLASH=y

# CONFIG_MCUMGR dependencies
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y

# Required for CONFIG_IMG_MANAGER
CONFIG_FLASH_MAP=y
CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="1.1.9+7"

CONFIG_BT=y

CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DIS=y
CONFIG_BT_DIS_PNP=n
CONFIG_BT_BAS=n
CONFIG_BT_HRS=n
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
CONFIG_BT_DEVICE_NAME="Zephyr Heartrate Sensor"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_DEVICE_NAME_DYNAMIC=y


CONFIG_I2C=y
CONFIG_CBPRINTF_FP_SUPPORT=y

CONFIG_GPIO=y
CONFIG_LED=y

CONFIG_COUNTER=y


CONFIG_MCUBOOT_USE_ALL_AVAILABLE_RAM=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y
CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y
CONFIG_NRF53_UPGRADE_NETWORK_CORE=y
CONFIG_UPDATEABLE_IMAGE_NUMBER=2
CONFIG_ADD_MCUBOOT_MEDIATE_SIM_FLASH_DTS=y


# Enable bonding
CONFIG_BT_SETTINGS=y

CONFIG_SETTINGS=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_I2C=y
CONFIG_CBPRINTF_FP_SUPPORT=y

# Enable DK LED and Buttons library
CONFIG_DK_LIBRARY=y

# This example requires more stack
CONFIG_MAIN_STACK_SIZE=1152
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Config logger


# HCI ACL buffers size
# BT_L2CAP_RX_MTU = CONFIG_BT_BUF_ACL_RX_SIZE - BT_L2CAP_HDR_SIZE
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_SIZE=251

# L2CAP SDU/PDU TX MTU
CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_HCI_VS=y
CONFIG_BT_HCI_VS_EXT=y

CONFIG_SERIAL=n
CONFIG_LOG=n

CONFIG_WATCHDOG=y
CONFIG_RESET=y

CONFIG_SHELL=n

CONFIG_LOG_CMDS=y

CONFIG_REGULATOR=y
CONFIG_SENSOR=y
CONFIG_I2C_SHELL=y
CONFIG_NRF_FUEL_GAUGE=y
CONFIG_REQUIRES_FLOAT_PRINTF=y


# CONFIG_FLASH_JESD216_API=y


CONFIG_NORDIC_QSPI_NOR=y


# CONFIG_PM=y
# CONFIG_PM_DEVICE=y

#### pwm
CONFIG_PWM=y
CONFIG_PWM_LOG_LEVEL_DBG=y

[Kenneth]

Hello,

Unfortunately I don't have any specific recommendations, but maybe you can search through your build folder for zephyr.dts and .config files, and share them here (with name of the folder you find them in the build folder)? Then I can take a look.

Kenneth