BLE_GATTC_EVT_TIMEOUT: Possible causes?

[Marius Heil]

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)

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

[Hung Bui]

Hi Marius,

Could you upload the full trace ?

From the screenshot what I can see is that the Slave stalled after the a few ms after the request. I suspecting a hardfault crashed the Slave and it might be reset at that point already.

EmptyPDU at packet 155 is normal. Not that #154 and #155 are in the same connection event. The slave can only response to the write request in the next connection event.

There is one interesting thing is that #154 and #161 both are write request to handle 0x0e but one is to the handle on the server on the Slave and the other is to the server on the Master, respectively.

I would need the full sniffer trace to investigate more. I suggest you to check if there is any assertion or hardfault occurs.