CC2652R7: BLE can not disconnect after several connections.

I have attempted to update the SDK to the latest version 8.31.0.11, but the problem persists.

Hello Allen,

How many times do you run the re-connection process before this issue occurs? Do you have a Bluetooth LE sniffer log that you can share with us? Do you think it is possible that your are trying to initiate a connection right before you send GAPTerminateLinkRequest or once you have received the GAP event that the link has been actually terminated?

BR,

David

Hi David,

Hey Allen,

Is this issue consistently being reproduced? Also, could you clarify what you mean by the device is stuck? Is it unresponsive?

Best Regards,

Tarek D

Yes, the issue consistently being reproduced. The BLE protocol stack was stuck in the connect state and can not be exited, which cause the advertisement being unable to enable anymore. When the issue occurs, calling the GapAdv_enable() interface will always return the error code 0x18.

This is the process that we call the API for your review.

Hello Allen,

Understood! When this issue happens, is the central disconnecting from the peripheral, or vice versa? Or does it happen regardless of who initiates the disconnection? A packet sniffer log would be very helpful here.

Best Regards,

Tarek D

Hi Tarek,

The disconnection is always initiated by the peripheral. Because we enabled the bonding, if there any central which didn't bonding yet is connect to peripheral, peripheral will initiate the disconnection. 
We use a phone as the central. When this issue happened, even we close the phone's Bluetooth the peripheral still can not exit the connection state.

Hello Allen,

To be clear, this issue only happens after the device has established +100 connections right? Could you possibly share code or steps to replicate, since no packet sniffer log is available?

One way to track the issue would be to have 2 counters, one for connection established event and one for connection terminated, and see if those numbers match up. Also, using the API linkDB_NumActive() when the issue happens should let us know whether the connection is indeed being terminated or not. Please try these out and let me know what you find.

Best Regards,

Tarek D

Hi Tarek,
When the issue occurs, the terminated event is one less than established event. The API GapAdv_enable return error code 24(0x18). And the API linkDB_NumActive()  return 1 indicate there is still one connection. And our device supports at most one connection.
[2025-11-05 11:02:49]#GapAdv_enable RETURN STATUS:#24
[2025-11-05 11:02:49]#established_count#612
[2025-11-05 11:02:49]#terminated_count#611
[2025-11-05 11:02:49]#Current link num:#1

Hello Allen,

This is certainly unexpected behavior, and I'm sorry you are running into this issue! Do you happen to have steps to replicate this issue? I would like to be able to see this issue on my end to run the necessary tests that would help me determine the cause of the issue.

Best Regards,

Tarek D

Hi Tarek,
It's very difficult to describe the reproduction steps. We've switched to the FreeRTOS operating system and also made some changes to the business logic, so unfortunately I'm unable to provide clear reproduction steps. Could you please guide me on how to further investigate and pinpoint the root cause of this issue?