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.

[Marius Heil]

Hi, i uploaded it here:

www112.zippyshare.com/.../file.html

The slave did not crash, there was no hardfault or anything. I had my UART logger open. The slave ran into a handshake timeout (the packets you are seeing are my custom handshake) and then it continued to connect to other devices with the same result.

Interesting, why are 154 and 155 in the same event if only an empty PDU is sent? I use one handle for communication purpose. Whatever is written to this handle is used as a kind of serial-data transfer. It will trigger a handler on the node that will process the message.

[Hung Bui]

Hi Marius,

You mentioned I do have one beacon that will produce a similar fault very realiable what is special aabout that beacon ?

Is it easy to reproduce the issue on the beacon ?

If you only test with 1 pair of device would that happen?

If there is no assertion or hardfault, I assume you will receive DISCONNECTED event , could you check which is the disconnected reason?

Do you have any slave latency on the peripheral side ?

Do you have any interrupt or other thing that may block the BLE events to be handled in the application ? If you failed in pulling out the BLE event from the stack, it may run out of buffer and can't process the write request.

Regarding your question, the softdevice always prepares what it plan to send in the next connection event prior to the event. In this case, the slave has nothing to send to the master, so it simply sends empty PDU. You can find which packet are in same connection event by looking either at the channel the packets are in, or you can look at the delta time end to start between packets.

If you can provide a simplified code that can reproduce the issue, it would be very helpful

[Marius Heil]

Nothing special from the outside, a developer dongle just like the others, but even after reflashing, it has these kind of connections problems which I cannot figure out.

I only have to plug it in and have another beacon around and they will connect, but the connection will break.

I will test with one pair of devices tomorrow and post the results. I do the disconnection manually after two seconds because that is part of the handshake. So I get local and remote host disconnect. I could remove this timeout and see what the disconnect reason will be, but I gues it will be a GATTC_EVT_TIMEOUT, the same problem that I have with my other beacons.

I do not use slave latency.

I do not use special interrupts, I use Uart and Button interrupts, but these are lower priority.

I do also pull all events and other following events are processed happily. I have many logs now which I am analyzing.

[Marius Heil]

What would happen if I were to slow to fetch all events from the event buffer? Would a BLE_GATTS_EVT_WRITE get lost inbetween and would never be answered by the SoftDevice? I have added two logs here from two connected nodes. Each of the nodes has other connections, but I filtered the log to show only the communication between the two. (TX_COMPLETE is generic though).

Log A: http://i.imgur.com/bgdIyoN.png

Log B: http://i.imgur.com/Bi7FMXZ.png

At one point, node A sends a packet (marked with (4) at the beginning of the line), but node B does never receive this packet. Nor does it receive any BLE_GATTS_EVT_WRITE event. The WRITE_RSP after (4) is just the current event that is being processed, it is not a write response to this very packet. I read all coming events.

After this, the connection is ended 30 seconds later with a BLE_GATTC_EVT_TIMEOUT. Any clues how I could proceed?