MTU negotiation problem

[dingari]

I'm facing a rather strange problem with an nRF52832 board I'm developing for. I'm using SDK 15.2 and S132 v6.0.0.

Sometimes, during the connection/negotiation phase, my device seems to get stuck in a weird state and can't send notifications. I've examined my logs and found out that when it works, I receive BLE_GATTC_EVT_EXCHANGE_MTU_RSP, and when it gets stuck, there is no such event received.

This is an example of a failed connection attempt:

<info> app: BLE_GAP_EVT_CONNECTED, conn handle: 1, role: 1
<debug> app: max_conn_interval: 11 ms
<debug> app: min_conn_interval: 11 ms
<debug> app: slave_latency: 0 connection events
<debug> app: conn_sup_timeout: 2000 ms
<debug> nrf_ble_gatt: Data length updated to 64 on connection 0x1.
<debug> nrf_ble_gatt: max_rx_octets: 64
<debug> nrf_ble_gatt: max_tx_octets: 64
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<debug> app: BLE EVENT: 0x0024
<debug> nrf_ble_gatt: Peer on connection 0x1 requested an ATT MTU of 515 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 64 bytes (desired: 64) on connection 0x1.
<debug> app: BLE EVENT: 0x0055
<debug> app: BLE EVENT: 0x0050
<debug> app: BLE_GATTS_EVT_WRITE, handle: 0x0017, len: 2
<error> app: Failed to notify, error: NRF_ERROR_INVALID_STATE (0x0008)

The central I'm connecting to is a Mac. This happens in the logs on the central:

default	12:11:12.512164+0000	bluetoothd	Sending MTU Request - MTU:515 Transport:2
default	12:11:12.555573+0000	bluetoothd	Received MTU Response - Response:64 Requested:515 Transport:2

This is an example of a successful attempt:

<info> app: BLE_GAP_EVT_CONNECTED, conn handle: 1, role: 1
<debug> app: max_conn_interval: 11 ms
<debug> app: min_conn_interval: 11 ms
<debug> app: slave_latency: 0 connection events
<debug> app: conn_sup_timeout: 2000 ms
<debug> nrf_ble_gatt: Data length updated to 64 on connection 0x1.
<debug> nrf_ble_gatt: max_rx_octets: 64
<debug> nrf_ble_gatt: max_tx_octets: 64
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<debug> app: BLE EVENT: 0x0024
<debug> nrf_ble_gatt: Peer on connection 0x1 requested an ATT MTU of 515 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 64 bytes (desired: 64) on connection 0x1.
<debug> app: BLE EVENT: 0x0055
<debug> nrf_ble_gatt: ATT MTU updated to 64 bytes on connection 0x1 (response).
<debug> app: BLE EVENT: 0x003A
<debug> app: BLE EVENT: 0x0050

And the central:

default	12:14:35.229238+0000	bluetoothd	Sending MTU Request - MTU:515 Transport:2
default	12:14:35.260755+0000	bluetoothd	Received MTU Request - MTU:64 Transport:2
default	12:14:35.264938+0000	bluetoothd	Received MTU Response - Response:64 Requested:515 Transport:2

Is there anything obvious that could be missing in some parameters/negotiation steps?

[Simonr]

Okay, then the SoftDevice should handle this on its own. You should check how you're enabling notifications from your central. Where in your application do you do this?

Best regards,

Simon

[dingari]

Hi Simon,

Just wanted to let you know that  there are two people answering this thread.

I've gone around this problem for now by simply not requesting an MTU update from the peripheral. If I have time, I'll check out your suggestions. Maybe it would be better for Marco Pennacchietti to start their own thread for this problem?

[Marco Pennacchietti]

Hi,

for now I have resolved my problem, is not the best solution but all work now.

I have removed the MTU request from nordic after connection in "on_connected_evt".

In IOS:

I have tested all IOS version from IOS >=10 with bluetooth 4.0, 4.2 and 5.1. IOS always sends the MTU request (185 byte) and my application work good.

in Android:

The android phone don't send the MTU request, so I have insert this request in android application. This is possible only with android >= 5.0.

In this case I excluded the old android 4.4 from compatibility with my system

Marco