• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 50 subscribers
  • Views 543 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GATT stop responding after few minutes of communication.

Sasha Kalmanovich
Intellectual 840 points

I wrote a small aplication based on the sample project, that uses WriteNoResponse commands to transfer data from KeyFob to USB dongle.

I am aiming at data rate of ~2KByte/sec. My settings are 25ms connection interval, 0 slave latence.

I transmit messages of the maximum size - attributes of 20 bytes. In each connection event, 3 messages are transmitted.

The application is working fine for a minute or two, and than it seems that the GATT layer of the BLE stack stops working.

The link layer continues to work - I see in the sniffer that link layer acks are transmitted at connection events.

But when messages are sent to the KeyFob, they are no longer passed to the application layer - the simpleProfile_WriteAttrCB function is not called anymore.

Any ideas ?

Thanks.

  • 0
    TI__Genius 17975 points

    Out of curiosity, have you tried using the standard Write Response instead of WriteNoReponse? Also, have you tried slowing down the connection and seeing if you still get a similar failure after a certain amount of time?

  • 0 in reply to Willis1
    Intellectual 840 points

    I can not use write response because it is a sequential command, and I can queue the next write request only after the response for the previous one has been received. This is very inefficient.

    I noticed however, that with longer connection intervals the problem occurs less. 

    I also noticed that I receive many HCI_BUFFER_NOT_AVAILABLE errors when queuing write no response commands. Maybe it has to do something with this ? 

  • 0 in reply to Sasha Kalmanovich
    TI__Genius 17975 points

    Here is one possible cause of the HCI_BUFFER_NOT_AVAILABLE errors: since you are queuing 3 Tx packets at every connection event, if a packet is dropped and not acknowledged (the link layer has built in flow control, acknowledgements, and re-transmissions) by the peer device, then it will want to re-transmit the 3 packets at the next connection event. That means that this data will still be sitting in a buffer while you attempt to queue more data for the next connection event. The buffers will fill up, and then you will start to get HCI_BUFFER_NOT_AVAILABLE errors.

    This still would not explain why the WriteNoResponse command completely stops working. That issue sounds like it's due to a memory leak somewhere. Are you using dynamic memory allocation in your application? You should be able to check this by stopping execution when this issue occurs, and checking the OSAL memory manager to see if the heap is full.