This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE_GATTC_EVT_TIMEOUT: Possible causes?

Hello,

I am still having troubles with the BLE_GATTC_EVT_TIMEOUT. The problem is that the error is not happening frequently and is hard to reproduce. It is also hard to attach a sniffer to each connection (and the nRF sniffer doesn't even work reliably) Here is what I have:

  • Scatternet of 8 Beacons running as concurrent central and peripheral
  • I send Write Requests but after a while the communication stalls for 30 seconds
  • I receive a GATTC timeout

I do have one beacon that will produce a similar fault very realiable. All Beacons are nRF51 Dongles of newer age with the S130 v2. It will connect to other beacons, the exchange a few packets, but then the link only sends empty PDUs. (THIS MIGHT NOT BE THE SAME FAULT)

image description

Is this a fault that I could potentially have made in my code? It looks like the Acknowledgement is never sent, but how could I possible interfer in this process with my code? Isn't this the SoftDevice's fault? Is it possible that I can decide to not acknowledge a write or to block it? Why is packet 155 an empty PDU, why is it not acknowledged directly?

Marius

Parents
  • Hi Marius,

    Could you summarize the issue to make it a little bit clearer.

    We are dealing with the issue with just one particular board or it happens on other boards also ? How often do you see the issue ?

    We need to narrow down the issue and find a way to reproduce it in house here.

    If you test with only 1 pair of devices (one connection at a time) can you reproduce the issue ?

    Please try to let the disconnection occur normally on the peripheral side and check the disconnected reason.

    If you have, please send other sniffer trace that captured the issue when it happens. Then we could be able to find a pattern. I suspecting it was the issue when a write response comes with a write request in a same connection event.

    Regarding your question, if you are too slow to pull all event from event buffer, the softdevice will NACK the packet. But there will still be packets from slave, not just stalled like what we see here.

Reply
  • Hi Marius,

    Could you summarize the issue to make it a little bit clearer.

    We are dealing with the issue with just one particular board or it happens on other boards also ? How often do you see the issue ?

    We need to narrow down the issue and find a way to reproduce it in house here.

    If you test with only 1 pair of devices (one connection at a time) can you reproduce the issue ?

    Please try to let the disconnection occur normally on the peripheral side and check the disconnected reason.

    If you have, please send other sniffer trace that captured the issue when it happens. Then we could be able to find a pattern. I suspecting it was the issue when a write response comes with a write request in a same connection event.

    Regarding your question, if you are too slow to pull all event from event buffer, the softdevice will NACK the packet. But there will still be packets from slave, not just stalled like what we see here.

Children
No Data
Related