PRoC BLE Disconnect Error

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I'm having some trouble at the moment with a design I'm working on. I have one central device and two peripherals which take it in turn to connect to the central. The problem I'm having is that one of the peripherals is not disconnecting when a disconnection request is sent from the central. When the central then tries to reconnect to this peripheral it can't as the peripheral still believes it is connected and is therefore not advertising. I have debugged the peripheral in question and when the central calls CyBle_GapDisconnect the peripheral does not jump in to the stack handler; it's as though it never received the request. This is only intermittent, however, and it does work 90% of the time. 
This is the code which calls the disconnection api at the central end:

   


                    apiResult = CyBle_GapDisconnect(connectionHandle.bdHandle);
                    while (bleConnected == TRUE)
                    {
                        ServiceWDT ();
                        CyBle_ProcessEvents();
                    }
                    if (apiResult != CYBLE_ERROR_OK)
                    {
#                       ifdef SERIALDEBUG
                            UART_UartPutString("+Disconnection error");
                            UART_UartPutString("\r\n");
#                       endif
                    }
                    else if (apiResult == CYBLE_ERROR_OK)
                    {
#                       ifdef SERIALDEBUG
                            UART_UartPutString("Disconnected from device with handle: ");
                            sprintf (valueString, "%i", connectionHandle.bdHandle);
                            UART_UartPutString(valueString);
                            UART_UartPutString("\r\n");
#                       endif
                    }

   


The disconnection api never returns an error when this fault occurs so I'm at a bit of a loss as to what the issue is. Plus, the connection handle is always correct/same value. Also, the fact the peripheral connection does not time out is just as curious. 
Has anyone come across this, or a similar problem before?

0 Likes
9 Replies
Anonymous
Not applicable

If you intend to disconnect from an existing connection, the function
    CyBle_GapDisconnect() should be used.

   

what do you do after calling the CyBle_GapDisconnect()? Start scanning? Or ,if it is reconnecting automaticlly?

0 Likes
Anonymous
Not applicable

Hi. Yes, that is the function I am calling to disconnect. After the central calls CyBle_GapDisconnect the central starts scanning, looking for the second peripheral. The first peripheral starts advertising, once disconnected. The problem is that the first peripheral doesn't always get the disconnect command, and carries on as if still connected. 

0 Likes
Anonymous
Not applicable

In case anyone is interested/has the same issue it was caused by the stack. I was using an old BLE stack version (V2) and updating to the latest full release (V2.3) solved the problem. There is a note in the errata section of the datasheet regarding this issue.

0 Likes
Anonymous
Not applicable

Hi Simon,

   

Can you let me know how to check the BLE stack version and how to update it. I have encountered same issue.

   

Thanks 

0 Likes
Anonymous
Not applicable

Hello n.congvu,

   

The BLE version can be determined by opening the TopDesign.cysch of your project and opening up the BLE component.  Click the Click the Built-In tab on the BLE configuration dialog.  The CY_MAJOR_VERSION and CY_MINOR_VERSION values listed on that tab specify the stack version.

0 Likes
Anonymous
Not applicable

I'm seeing the same problem with BLE v3.1 & v3.2. Usually works, but maybe once in thirty connections, CyBle_GapDisconnect returns CYBLE_ERROR_OK, but the CYBLE_EVT_GAP_DEVICE_DISCONNECTED event is not called for 5-10 seconds. Further calls to CyBle_GapDisconnect  return CYBLE_ERROR_INVALID_PARAMETER.  CyBle_GetState() == CYBLE_STATE_CONNECTED remains true until CYBLE_EVT_GAP_DEVICE_DISCONNECTED event eventually arrives.

0 Likes
Anonymous
Not applicable

Appears the issue may be endemic to BLE. If the connection termination packets are lost, the recovery is by "Connection supervision timeout".

   

Reduced the magnitude of the problem on the peripheral by reducing the central "Connection supervision timeout".

0 Likes
Anonymous
Not applicable

Since packet loss is inherent in RF designs, the Connection Supervision Timeout is there specfically for instances such as these, where the peripheral doesn't receive the disconnect from the remote device, but is no longer connected.

   

You might be able to do some sort of keep-alive/ping method with BLE data transmission to keep a bead on whether the connection is still valid, but that is probably more trouble than it is worth.

0 Likes
Anonymous
Not applicable

Hallo Simon, I am currently working with something similar.
Is it possibly that you could post or send your code?  
If not I fully understand 

0 Likes