How to correctly set MTU size in Nordic Connect SDK V2.0?

[MehdiZ]

Hello,

I setup a BLE Peripheral that advertises a service with 2 notifications. Each notification has 240 bytes of payload data. When I connect with a client and subscribe to either one, I have the following output on the serial monitor (I modified the debug output to print the value of chan->chan.tx.mtu inside sdk function bt_att_create_pdu() ) :

[00:07:27.777,038] <wrn> bt_att: No ATT channel for MTU 247, max is 0
[00:07:27.777,069] <wrn> bt_gatt: No buffer available to send notification
[00:07:27.780,517] <wrn> bt_att: No ATT channel for MTU 247, max is 0
[00:07:27.780,517] <wrn> bt_gatt: No buffer available to send notification

I checked the throughput example and modified my .conf files accordingly, also added a chi_rpmsg.conf file. With the current configuration files I have 0 warnings and errors during a pristine build.

These are the contents of both files:

prj.conf:

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

CONFIG_NRFX_RTC0=y
CONFIG_NRFX_GPIOTE=y

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_MAX_CONN=1
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_APPEARANCE=962
CONFIG_BT_DEVICE_NAME_DYNAMIC=y

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=10
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=200
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=3000

# Over-ride various BT settings for extended data packet size
CONFIG_BT_ATT_PREPARE_COUNT=4
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_TX_FRAG_COUNT=15
CONFIG_BT_BUF_EVT_RX_SIZE=251
CONFIG_BT_BUF_CMD_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_COUNT=15
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_CMD_TX_COUNT=10
CONFIG_BT_CONN_TX_MAX=15
CONFIG_BT_L2CAP_TX_BUF_COUNT=15

CONFIG_BT_GATT_CLIENT=y

CONFIG_HEAP_MEM_POOL_SIZE=2048

# This example requires more workqueue stack
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

hci_rpmsg.conf:

CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_CTLR_ADV_EXT=y
CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=251
CONFIG_BT_CTLR=y
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=6000
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_RX_BUFFERS=2

Can you please take a look and see if you find any errors?

Best Regards,

Mehdi

[Hung Bui]

Hi Mehdi, 
You may want to capture a sniffer trace so we get to understand what happens over the air. 
I suspect that the ATT MTU negotiation didn't happen and you don't have the MTU = 247 so you can't send the notification of that size. 
Note that the throughput example requires the control from both sides. Actually it's the central that request the ATT MTU update. 

I have made a blog and an example to test throughput. You can have a look here. The example when act as a peripheral will pro-actively request ATT MTU exchange to increase the MTU. 

[MehdiZ]

Thank you for your help.

I tested the peripheral_uart as is and it works correctly although there are some warnings during build phase

warning: BT_CTLR_DATA_LENGTH_MAX (defined at
/opt/nordic/ncs/v2.0.0/nrf/subsys/bluetooth/services/fast_pair/Kconfig.fast_pair:83,
/Users/mehdizemzem/nRF53/peripheral_uart_throughput/build/subsys/bluetooth/controller/Kconfig:379) was assigned the value '251' but got the value ''. Check
these unsatisfied dependencies: ((BT_FAST_PAIR_GATT_SERVICE && BT_FAST_PAIR && BT) ||
(BT_CTLR_DATA_LENGTH && BT_CONN && BT_CTLR && BT_HCI && BT)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_CTLR_DATA_LENGTH_MAX and/or look up
BT_CTLR_DATA_LENGTH_MAX in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.


warning: BT_SETTINGS (defined at /Users/mehdizemzem/nRF53/peripheral_uart_throughput/build/subsys/bluetooth/host/Kconfig:169,
/Users/mehdizemzem/nRF53/peripheral_uart_throughput/build/subsys/bluetooth/host/Kconfig:169) was assigned the value 'y' but got the value 'n'. Check these
unsatisfied dependencies: ((SETTINGS && BT_HCI_HOST && BT_RPC_STACK) || (SETTINGS && BT_HCI_HOST &&
BT_HCI && BT)) (=n). See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_SETTINGS and/or
look up BT_SETTINGS in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.


warning: BT_PRIVACY (defined at /Users/mehdizemzem/nRF53/peripheral_uart_throughput/build/subsys/bluetooth/host/Kconfig:322,
/Users/mehdizemzem/nRF53/peripheral_uart_throughput/build/subsys/bluetooth/host/Kconfig:322) was assigned the value 'y' but got the value 'n'. Check these
unsatisfied dependencies: ((BT_SMP && BT_CONN && BT_HCI_HOST && BT_RPC_STACK) || (BT_SMP && BT_CONN
&& BT_HCI_HOST && BT_HCI && BT)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_PRIVACY and/or look up BT_PRIVACY in the
menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.

I retested my code with the nRF BLE desktop app and this is the log I have for now:

14:27:27.705	Scan started
14:27:29.207	Connecting to device
14:27:30.028	Connected to device F6:2B:E4:76:38:34: interval: 7.5ms, timeout: 4000ms, latency: 0
14:27:30.070	Data length updated for device F6:2B:E4:76:38:34, new value is 251
14:27:30.156	Phy updated for device F6:2B:E4:76:38:34, tx: 2 Mb/s, rx: 2 Mb/s
14:27:30.315	Attribute value read, handle: 0x0B, value (0x): 5A-65-70-68-79-72
14:27:34.401	Attribute value changed, handle: 0x13, value (0x): 01-00
14:27:34.407	Attribute value written, handle: 0x13, value (0x): 01-00
14:27:35.078	Connection parameters updated for device F6:2B:E4:76:38:34: interval 12.5ms, timeout 30000ms, latency: 0

Can you recommend another sniffer to use?

On the bright side, I solved my problem by adding the following functions to my code:

static int update_connection_parameters(void);
static void request_mtu_exchange(void);
static void request_data_len_update(void);
static void request_phy_update(void);
static void MTU_exchange_cb(struct bt_conn *conn, uint8_t err, struct bt_gatt_exchange_params *params);
static void le_phy_updated(struct bt_conn *conn,
			   struct bt_conn_le_phy_info *param);
static void le_data_length_updated(struct bt_conn *conn,
				   struct bt_conn_le_data_len_info *info);

I suppose that what you said is correct about the ATT MTU negotiations