• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 325 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.

CC2652P7: The device does not receive a disconnect event.

Nick Braun
Prodigy 110 points
Part Number: CC2652P7


Tool/software:

Hello
I have two devices, one connects to the other. Due to some conditions, I see that the connection is established on the slave device, but it is immediately broken with the status 0x3D. This status is associated with incorrect encryption keys during pairing. But, regardless of the reason for disconnection, the device that initiated the connection does not receive this disconnection event and thinks that the connection is present. On the initiator side, the connection is broken later and under the timeout condition.
Why do I not see the disconnection event on the master side, when on the salve side it was? How can I confirm that I receive these events correctly?

  • 0
    TI__Mastermind 42870 points

    Hi Nick,

    Can you specify the SDK version you are using? Does the central device hang or stop responding after the disconnection occur?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    Hi
    i am writing my own app, but based on SDK 7.41
    And no, it doesn't look like the devices are hanging, but they record connection breaks at different times and for different reasons. The peripheral device on its side breaks the connection for reason 0x3D. And the central device records the connection break much later for reason 0x08 (timeout). Why doesn't it record the break at the same time and for the same reasons as the peripheral? It looks like the break message doesn't reach it, but that's just a guess.

  • +1 in reply to Nick Braun
    TI__Mastermind 42870 points

    Hi Nick,

    Got it. Thank you for the details. Based on the information you have provided, I believe you are seeing that the central for some reason is not receiving the terminate event and continues to operate as if the connection is still alive. In this case, the expected behavior is for the central to not assume the connection was lost until a period of time equal to the connection supervision timeout has elapsed from the last packet received from the other device. If desired, you may increase or decrease the supervision timeout depending on  if you want a quicker detection time or more robust connection.

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 110 points

    Hi

    I see. But is there any way to determine that the central device has received/not received the connection break message? Or to guarantee that it has definitely reached the addressee? Something like a write operation with confirmation.
    Or is the system designed so that the peripheral device sends a connection break message and does not care how it was received by the other side?

  • 0 in reply to Nick Braun
    TI__Mastermind 42870 points

    Hi,

    I believe if the central attempts to write/read a characteristic of the peripheral after it has lost track of the connection, that may quickly trigger a disconnection. If I am not mistaken, in BLE the peripheral does not wait for an acknowledgement after sending the link terminate message.

    Best Regards,

    Jan