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 Marius, 

I'm sorry that this old issue is remained after a long time. Could you please make a fresh sniffer trace with the new softdevice ? 

It would be the best if we can find a way to reproduce the issue here with the minimal code. 

[Marius Heil]

Hello, I will be on parental leave for some time, so I might need to do that at a later time. i was hoping that this was a known issue or that it was reproducable with the old traces. As this happens very infrequently and in my case in a network with around 70 nodes, it is very hard for me to track down. I think it should happen when setting up a device with a peripheral and 3 central connections and then sending a mixture of write_cmd and write_req from all nodes to flood the small network of 4 nodes. But I don't currently have the time to set this up.

[Hung Bui]

Hi Marius, 

We will try to reproduce the issue here.

The biggest challenge is that it happened for you infrequently and we are not 100% sure it would be possible to reproduce with a small network. Last time (on the trace 2 years ago) we concluded that there was something that triggered a disconnection after 30 seconds. There was a corrupted packet at the point of interest but we are not sure if that triggered the issue. 

How infrequently have you experienced the issue ? Just so we know what to expect. 

[Marius Heil]

Hi, the disconnect after 30 seconds is done by me, as this is when the gattc timeout happens and I have to disconnect because the connection does not allow me to queue packets anymore. In a network with 20 nodes, I only had it once in a week. But it only happens during reclustering which does not happen very often. I would guess that it happens after a few minutes in a network with 10 nodes when the network is flooded with these packets.

[Hung Bui]

Hi Marius, 

Sorry for the late response. I have setup a small test here and it seems that I can reproduce the issue. BLE_GATTC_EVT_TIMEOUT event triggered  multiple times in the test. I don't know what could be the problem or if it's a bug with the softdevice yet. But I will let you know if we find something. 

[Michal]

Great to hear you were able to reproduce it ! Marius is on a vacation right now but I will be able to speak in his name. Would be nice if this can be fixed, right now we hade to remove all WRITE_REQ from code.

[Hung Bui]

Hi Michal, 

Further investigation showed that it's one of the bug that we had found and fixed in S132 v6.0.0

It's described in the release note of S132 v6.0.0 as: 

Fixed an issue where the SoftDevice could drop a write request if it was received at the same time as a write command (DRGN-9709).

Is it possible for you to upgrade the softdevice to v6.0.0 or newer ? I think it's the best option, otherwise we would need to look into how we can avoid the corner case when the softdevice drop the write request on the server side.