Still trouble with BLE_GATTC_EVT_TIMEOUT

[Marius Heil]

Hello,

I was having a lot of trouble with BLE_GATTC_EVT_TIMEOUT on the nRF51 and softdevice v2. But now I continue to have the same problems on an nRF52 with Softdevice v5.1.0. Below is a short description of what I am doing:

- Forming a scatternet of multiple nodes as a spanning tree using https://github.com/mwaylabs/fruitymesh/

- Sending data through this network with both WRITE_REQ and WRITE_CMD

- All network participants are the same nRF52 chipset with S132 5.1.0

=> When I send a larger numbe rof WRITE_REQ, some of my nodes will randomly run into the BLE_GATTC_EVT_TIMEOUT. This does not happen when I only send WRITE_CMD.

This seems to be a Softdevice Bug and I now reverted and went back to using WRITE_CMD, but this is not a solution. I have used WRITE_CMD for a long time now to mitigate the issue, but I thought this would have been fixed in the latest Softdevice.

See here my old questions about the same issue:

https://devzone.nordicsemi.com/f/nordic-q-a/19878/ble_gattc_evt_timeout-possible-causes/77361#77361

https://devzone.nordicsemi.com/f/nordic-q-a/11142/connection-stability-with-s130/41760#41760

[Hung Bui]

Hi Michal, 

In order to calculate the buffer needed, could you let me know the ATT_MTU using in your mesh ? Is it 23 or larger? 

I assume your mesh only uses WRITE_CMD, WRITE_REQ and doesn't use notification/indication ? 

[Michal]

ATT_MTU is 23 bytes. In some situations we are using notifiactions as well but mostly writes.

[Hung Bui]

Could you try to test with the following: 

- Set the NRF_SDH_BLE_GATT_MAX_MTU_SIZE to 300 (you still can use 23 byte as the preferred MTU)

- Set the configuration with sd_ble_cfg_set() with  ble_cfg.conn_cfg.params.gattc_conn_cfg.write_cmd_tx_queue_size = 1 (BLE_CONN_CFG_GATTC)

- Set the configuration with sd_ble_cfg_set() with  ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size   = 1 (BLE_CONN_CFG_GATTS)

- Use a buffer counter to avoid queuing more than 6 packets at anytime. This means you keep track of the number of buffer you are using by counting the number of success queue of write command (and notification) and the number of packet sent (count)  in BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE and BLE_GATTS_EVT_HVN_TX_COMPLETE if you use notification. Delay sending if you have used all 6 packets. 

I had a quick test overnight here and it seems to work.