nRF52833: MTU Exchange Fails and Connection Terminates

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Simonr — Tue, 05 May 2026 08:18:00 GMT

Hi Ashwini

I'm sorry about the late reply here, but I've been indisposed the last week and are only now catching up to my case queue.

In order to get more logging information, can you set these configs in your project's .conf file so it's easier to see if we get more from the logging on this side. The disconnect reason from your log here seems to point to it being the device on the other end that initiates the disconnection in the first place.

CONFIG_BT_LOG_LEVEL_DBG=y

CONFIG_LOG_BACKEND_UART_BUFFER_SIZE=8192

CONFIG_LOG_BUFFER_SIZE=8192

Best regards,

Simon

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Fri, 24 Apr 2026 16:15:59 GMT

Hello Simon,

I m using custom board and using internal RC configuration.

In connection i m coonectinf device with uuid once connection is established then discovery started and notify and got data .

these are some logs [00:13:56.085,479] <inf> main: CONNECTED
[00:13:56.387,237] <inf> main: MTU: 247
[00:13:56.487,579] <inf> main: Starting discovery for custom UUID
[00:13:56.587,158] <inf> main: Found service, start_handle: 0x0010, end_handle: 0x0015
[00:13:56.687,927] <inf> main: Characteristic handle: 0x0012
[00:13:56.787,170] <inf> main: CCCD handle: 0x0013
[00:13:56.887,268] <inf> main: Discovery complete in discover function
[00:13:58.887,023] <inf> main: Received notification from F8:E2:EC:CB:B5:83 (random), with valide data len: 0
[00:13:58.887,512] <inf> main: Disconnected: 0x13

From logs discovery complete and notification received from tag is time is about 2sec . is because of this connection is terminating.

Thanks ,

Ms. Ashwini L Pujari.

Embedded Firmware Developer,

EMBEL Technologies Pvt Ltd.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Simonr — Fri, 24 Apr 2026 07:49:12 GMT

I'm not able to see any good indications of what exactly is causing the disconnects in these sniffer logs, as they just seem to do normal transmissions before suddenly the peripheral terminates the connection. If you select which device to sniff, you get a better overview of just that device and the connections it's in. Do you do any kind of encryption (pairing/bonding) during connection? If so we might be missing vital encrypted packets here that can be found if you follow the documentation here: https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-ble-sniffer/guides/common_sniffing_actions.html

The error 0x3e can also be due to the internal clock configuration being wrong as well. Are you working on custom boards or with a DK?

Best regards,

Simon

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Thu, 23 Apr 2026 07:26:35 GMT

Hello Simon,

I have attached ble sniffer logs where sometimes got data from tag and some times its failed .devzone.nordicsemi.com/.../220426_5F00_night_5F00_log-checkuart2-log-for-verification.pcapng

Thanks ,

Ms. Ashwini L Pujari.

Embedded Firmware Developer,

EMBEL Technologies Pvt Ltd.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Wed, 22 Apr 2026 08:11:44 GMT

Hello Simon,

I also want to mention that cf:dd:bd:9f:11:77 connecting some times but no of times it failed .

it not connected is not a case , it actually failed no of times .

Waiting for your responce.

Thanks ,

Ms. Ashwini L Pujari.

Embedded Firmware Developer,

EMBEL Technologies Pvt Ltd.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Wed, 22 Apr 2026 07:47:46 GMT

Hello Simon,

I m working on nrf connect sdk and this is my project config file pr.conf attached here. devzone.nordicsemi.com/.../73202.prj.conf

Now i m also attached ble sniffer where d1:75:3d:ba:3a:25 central device makes successfully connection with ble tag and receive data from tag , but cf:dd:bd:9f:11:77 central device not making connection successful why?

devzone.nordicsemi.com/.../WHERE-NOT-CONNECTION-FOR-BOARD-AND-NEXT-GOT-CONNECTION-FOR-D125.pcapng

Please check the log of ble sniffer and let me know the reason why cf:dd:bd:9f:11:77 not establishing connection with ble tag.

Waiting for your responce.

Thanks ,

Ms. Ashwini L Pujari.

Embedded Firmware Developer,

EMBEL Technologies Pvt Ltd.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Simonr — Tue, 21 Apr 2026 07:27:30 GMT

The error 0x3e can also be due to the internal clock configuration being wrong as well. Are you working on custom boards or with a DK?

Best regards,

Simon

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Mon, 20 Apr 2026 07:44:25 GMT

Hello Simonr,

I don't have log of BLE Sniffer but will provide you soon .

Now let me the reason where BLE connection failed.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Simonr — Wed, 15 Apr 2026 09:21:52 GMT

Would you be able to provide a sniffer trace of the connection and MTU exchange so we can get a better look at what is going on over the air here. Either with a dedicated Bluetooth sniffer like the Ellisys tracers, or with an nRF5 series DK/Dongle with the nRF Sniffer firmware and Wireshark.

Best regards,

Simon

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Tue, 14 Apr 2026 05:41:15 GMT

Hi Simonr,

I am using nRF52833 with nRF Connect SDK for VS Code (v2.9.0) on the central side.

The MTU size has been configured on the central side, and I have also configured the data length parameters accordingly. Please find attached the prj.conf file from the central side for your reference.

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# ─── UART (Async, no console) ───────────────────────────────────────────────
CONFIG_SERIAL=y
CONFIG_UART_ASYNC_API=y
CONFIG_NRFX_UARTE0=y
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n


# ─── FOR UART STOP and RESTART AT RUNTIME WHEN UART RX ERROR EVT TRIGGERS ─────────────────────
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y


# ─── BLE Stack (Central / Scanner) ──────────────────────────────────────────
CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_SMP=y

# BLE NCS modules
CONFIG_BT_NUS_CLIENT=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1
CONFIG_BT_GATT_DM=y

# MTU / buffer sizing for 40-byte chunks
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

# BLE stack sizes
CONFIG_BT_RX_STACK_SIZE=4096

# Reduce BLE log noise — only errors
CONFIG_BT_LOG_LEVEL_ERR=y

# ─── Stack / Heap ────────────────────────────────────────────────────────────
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_HEAP_MEM_POOL_SIZE=4096

# ─── RTT Logging (no UART backend) ──────────────────────────────────────────
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=y
# 23rd March 2026, RTT BUFFER SIZE increased for crash log capture
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=4096
# ─── GPIO / SPI (needed for nRF21540 FEM) ───────────────────────────────────
CONFIG_GPIO=y
CONFIG_SPI=y

# ─── RTC Calendar ────────────────────────────────────────────────────────────
CONFIG_RTC=y
CONFIG_RTC_UPDATE=y

# ─── Watchdog ────────────────────────────────────────────────────────────────
CONFIG_WATCHDOG=y
CONFIG_REBOOT=y

# ─── Clock (RC low-frequency, 500 ppm) ───────────────────────────────────────
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

# ─── Range Extender: nRF21540 FEM ────────────────────────────────────────────
CONFIG_MPSL=y
CONFIG_MPSL_FEM=y
CONFIG_MPSL_FEM_NRF21540_GPIO_SPI=y
CONFIG_MPSL_FEM_NRF21540_TX_GAIN_DB=20
CONFIG_MPSL_FEM_POWER_MODEL=y
CONFIG_MPSL_FEM_POWER_MODEL_NRF21540_USE_BUILTIN=y
CONFIG_BT_CTLR_TX_PWR_ANTENNA=20

# ─── Assert ──────────────────────────────────────────────────────────────────
CONFIG_ASSERT=y

# ─── Heap runtime stats (optional, useful for debugging) ─────────────────────
CONFIG_SYS_HEAP_RUNTIME_STATS=y

# ─────────── prj.conf ADDDED ON -> 9th MARCH for CRC CHECK ──────────────────────
CONFIG_CRC=y

# ─── Fatal Error Debugging 10th MARCH 2026, ───────────────────────────────────────────────────
CONFIG_RESET_ON_FATAL_ERROR=n       # Prevent immediate reboot so output is visible
CONFIG_THREAD_NAME=y                # Show thread name (e.g. "main") instead of "unknown"
CONFIG_ASSERT=y
CONFIG_ASSERT_VERBOSE=y
CONFIG_ASSERT_NO_COND_INFO=n
CONFIG_ASSERT_NO_MSG_INFO=n
# Stack overflow detection
CONFIG_HW_STACK_PROTECTION=y
CONFIG_INIT_STACKS=y
# Immediate logging ensures crash logs are flushed before halt
CONFIG_LOG_MODE_IMMEDIATE=y



#────────────────────────────  THREAD ANALYZER FOR STACK OVERFLOW DETECTION ──────────────────────
#CONFIG_THREAD_NAME=y

#CONFIG_THREAD_ANALYZER=y
#CONFIG_THREAD_ANALYZER_AUTO=y
#CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
#CONFIG_THREAD_ANALYZER_USE_LOG=y
#CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=30
#CONFIG_THREAD_ANALYZER_AUTO_STACK_SIZE=2048

#CONFIG_INIT_STACKS=y

At the moment, I do not have configuration details from the peripheral side, as the peripheral device (tag) has been provided by the client. Therefore, I am not able to confirm whether the MTU size and data length settings are matched on the peripheral side.

Regarding the test environment, testing is being performed in a standard indoor environment.

Please let me know if you need any additional logs or configuration details from the central side.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Simonr — Mon, 13 Apr 2026 13:05:31 GMT

Have you set the MTU size and data length size to support the same size in both central and peripheral It seems like the MTU size is set correctly, but the data length also needs to be set correctly to allow for larger data lengths. In what kind of environment are you testing for here, because it seems like there is a disconnect during the data transfer, possibly due to the surrounding environments.

Best regards,

Simon

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Embel_Tech — Fri, 03 Apr 2026 06:04:11 GMT

The peripheral in this setup is also an nRF device.

In my application, I am not storing any bonding information. The scanner-side execution flow, as shared previously, does not include any steps related to bonding or maintaining persistent pairing data.

Given this, I would appreciate your guidance on how to further investigate and improve the MTU exchange failure observed from the scanner (central) side.

Looking forward to your suggestions.

RE: nRF52833: MTU Exchange Fails and Connection Terminates

Simonr — Wed, 01 Apr 2026 06:09:10 GMT

What device is the peripheral here? Is it an nRF device as well or something else? I'm trying to find references to what this -128 error is, which should only point to the devices not being connected.

The multiple 0x3E errors are indeed pointing to connection failed to be established, and this could be due to one of the devices having stored pairing information that the other does not. Can you try erasing the bonding information on both devices before trying to connect again? If you don't have a way to do so, nrfutil device recover to recover the device before flashing them again should also erase bonding information.

Best regards,

Simon