• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 52 subscribers
  • Views 2948 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.

GAP link terminated because of GAPROLE_WAITING_AFTER_TIMEOUT

Gergo Zsiak
Intellectual 855 points


Hi All,

After connecting and discovering characteristic values I get GAP_LINK_TERMINATED_EVENT and the reason is 0x3F, which code can't  be foun ind the vendor specific HCI guide, but I think it's defined in ll.h (link layer):

#define LL_STATUS_ERROR_CONN_TIMING_FAILURE            0x3F // MAC Connection Failed

What does MAC stand for in this context? What can cause this error? I tried to set another connection parameters, but nothing helped. Do you have any ideas?

 

Thanks,

Gergo

  • 0
    Intellectual 855 points

    Any suggestions? I haven't got rid of it yet, and don't have any ideas.

    Thanks,

    Gergo

  • 0
    TI__Guru 57865 points

    Hi Gergo,

    The Bluetooth Core specification says:

    2.60 MAC CONNECTION FAILED (0X3F), The MAC of the 802.11 AMP was requested to connect to a peer, but the connection failed.

    Can you try to connect and discover characteristic values from BTool? 

    BR

  • 0 in reply to J Lindh
    Intellectual 855 points

    Hi Nick,

     

    Thanks for your reply. I test it with my own method, sending debug messages with UART to the PC. The Central (GATT client) discovers the four characteristic values defined on the server side (GAP peripheral). This is done by calling  GATT_ReadUsingCharUUID four times one after the other  (with 0.5 sec timeout). After they have been discovered succesfully this error occurs all the time. The strange thing is that it doesn't depend on the time elapsed since the establishment of connection. I tried to only discover the first two charv's and the symptom was the same.

    I tried to vary connection parameters in many ways, but didn't help.

    One more strange thing which I am going to investigate is that a GATT ATT_READ_BY_TYPE_RSP comes always after the termination of connection. (No requests were sent after they had been discovered.)

    Do you have any ideas? Any help would be highly appreciated.

     

    BR,

    Gergo

     

    P.S.: another strange error which we can't get rid of: http://e2e.ti.com/support/low_power_rf/f/538/t/146829.aspx . It would be also very useful for me and my colleague if you have any suggestions. Thanks again.

  • 0 in reply to Gergo Zsiak
    Intellectual 855 points

    Hi Nick, 

    I've found that for every GATT_ReadUsingCharUUID request I get two responses. Both are the type of ATT_READ_BY_TYPE_RSP, the real handle comes with the first one. However, in the second message msg.readByTypeRsp.numPairs equals to zero. Is this the expected functioning? I don't think so, I keep on testing.

    BR,

    Gergo

  • 0 in reply to Gergo Zsiak
    Intellectual 855 points

    Some news after a few hours of testing. I'm now sure that the definition of the GATT profile is correct, and the peripheral-server side is OK as well. Therefore the problem should be in the central-client software. 

    BR,

    Gergo

  • 0 in reply to J Lindh
    Intellectual 855 points

    Hi,

    I think, I've got it. There was a ~1 second long delay after the discovery of charvalues, and I think this blocked the whole program, and caused the LL connection to be terminated because of timeout.

    Do you agree with me?

    BR,

    Gergo

     

  • 0 in reply to Gergo Zsiak
    TI__Guru 57865 points

    Hi Gergo,

    That makes sense, I assume that was your own delay?

    Great that it works for you now.

    BR

  • 0 in reply to J Lindh
    Intellectual 855 points

    Hi Nick,

    Yes, it was our our delay function. Furthermore, there was statement which waited for data to come via UART, and that also blocked the running of the program. Now it sounds absolutely reasonable, but it was really hard to find the bug starting from the error message. Luckily, I succeded :)

    Thanks for your comments!

    Gergo

  • 0 in reply to Gergo Zsiak
    Intellectual 320 points

    Gergo Zsiak said:

    Hi Nick, 

    I've found that for every GATT_ReadUsingCharUUID request I get two responses. Both are the type of ATT_READ_BY_TYPE_RSP, the real handle comes with the first one. However, in the second message msg.readByTypeRsp.numPairs equals to zero. Is this the expected functioning? I don't think so, I keep on testing.

    BR,

    Gergo

    Did anyody find the answer for this question? Why is that so?

    BR, Primoz