• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 307 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.

CC2642R: Peripheral: Need to disconnect the connection immediately without sending the terminate event to the client

Mehul Dalal
Expert 2180 points
Part Number: CC2642R

Hi,

I am using Simple Peripheral application as a base fimrware. I have a scenario where the peripheral is connected, but due to certain reason, it has to disconnect without sending the terminate request to the client. In such case, the client should have supervision timeout used for getting the disconnection.

But the simple peripheral has to ask the BLE to get out the connection immediately without sending the terminate request. I am currently using GAP_TerminateLinkReq() API with "HCI_DISCONNECT_REMOTE_USER_TERM"  reason. But it waits for the request to sent out on BLE channel in the connection and waits for the master to acknowledge it before terminating the connection. I do not want to wait for that much extensive period. I want the BLE stack to disconnect immediately.

  • 0
    TI__Guru** 101460 points

    Hi Mehul,

    The behavior you are describing is not Bluetooth LE compliant.

    However, I guess we can think about creative ideas together:

    • Have you considered using the function HCI_EXT_DisconnectImmedCmd ?
    • Would it be acceptable to trigger a reset of the device when the disconnection is required?
    • Would it be acceptable to stop all the RF operations when the disconnection is required? In such case, we could think about some hardware possibilities.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Expert 2180 points

    Hi Clement,

    Yes, I have used HCI_EXT_DisconnectImmedCmd command and it is working as I have expected where the connection is terminated immediately but the master will eventually timeout due to supervision timeout.

    Why do you consider using above API is non compliant? I believe that the peripheral is following the BLE spec and the supervision timeout is meant for that kind of scenario only other than out of range.

    I have answered to other question as well:

    • Would it be acceptable to trigger a reset of the device when the disconnection is required? --> You mean soft restart? If yes, then we cannot afford that.
    • Would it be acceptable to stop all the RF operations when the disconnection is required? In such case, we could think about some hardware possibilities. --> We are using this option partially using DMM RF Skip feature but the BLE stack is waking up on every connection interval with no RF and eventually, due to limited energy in the peripheral the brown out is observed which we would to avoid.

  • +1 in reply to Mehul Dalal
    TI__Guru** 101460 points

    Hi Mehul,

    My interpretation of BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part B, §4.5.12 is that a connection should be gently terminated.
    With that being said, I see your point, using HCI_EXT_DisconnectImmedCmd, the same kind of behavior (i.e. reach out the connection timeout then consider the connection as lost).
    From a Bluetooth qualification point of view, I *think* it will be ok. I mean, Bluetooth RF PHY tests cannot see this.

    With these pieces of information, I'll let you assess the direction you want to take.

    (Thank you for the answers you have provided - I am afraid the ideas I was thinking of would not work.)

    Best regards,