• State Not Answered
  • Replies 10 replies
  • Subscribers 67 subscribers
  • Views 5887 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 119877
Options
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?

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)

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
  • 0

    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

Reply
  • 0

    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

Children
No Data
Related