Recovering from getting Stuck in GAP Central

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

cross mob
AnYo_2347841
Level 1
Level 1
First reply posted First question asked Welcome!

Hi All,

I am using a CYBLE-202007-01 module. Every once in a while, after sending a BLE message, the node will stop responding to messages. If I take a look on my CySmart phone app, I can see that my module is no longer advertising. I have come to find that it gets stuck in Gap Central.

If I send a message every 30 seconds or so, the issue of getting locked in Central is less frequent, per amount of messages sent.

To prove that I was stuck in Central, I coded in a change of LED lights that would only occur if I was in GAP Central for more than 10 seconds. If anything, I should never be in Central for longer than 3 seconds.

I have to wonder if the BLE device is failing to disconnect my Android device properly. I have been programming in Android for years, and I know my connect/disconnect on that side is solid. Just in case I was wrong, I followed all of the connecting/disconnecting events in my Android logs to ensure this. I went further to write some extra Android code to list all my connected devices, and when this "stuck in central error" occurs, my Android device shows that it is not connected to any devices.

On the BLE side, I am using the below to disconnect devices.

if((cyBle_connHandle.bdHandle != 0)){

        CyBle_GapDisconnect(cyBle_connHandle.bdHandle);

        CyBle_ProcessEvents();

}

Though, i've also noted CyBle_GapDisconnect(0); to work as well

Is there a way to recover from being stuck in Central? I'm sure there is some type of error when the node fails to disconnect properly and the BLE node won't switch back to being a Peripheral (and restart advertising). I would even be willing to reset my system to it's initial state, but I haven't found that to be possible from my searching.

0 Likes
3 Replies
Anonymous
Not applicable

BLE advertising isn't connected with Central, but rather Peripheral. So, I'm confused when you say the device is in Central mode but is not advertising?

The Central device is the one controlling the wireless connection/interaction, and the Peripheral device is merely the one responding and being controlled by the Central device (more or less).

I think this information from the documentation is what you are looking for:

/******************************************************************************

* Function Name: CyBle_GetState

***************************************************************************//**

*  This function is used to determine the current state of the component

*  state machine.

*

*  The component is in the state CYBLE_STATE_INITIALIZING after CyBle_Start()

*  API is called and until CYBLE_EVT_STACK_ON event is not received. After

*  successful initialization the state is changed to CYBLE_STATE_DISCONNECTED.

*  For GAP Peripheral role if CyBle_GappStartAdvertisement() API is called and

*  CYBLE_EVT_GAPP_ADVERTISEMENT_START_STOP event received the state is changed

*  to the CYBLE_STATE_ADVERTISING. For GAP Central role if CyBle_GapcStartScan()

*  API is called and CYBLE_EVT_GAPC_SCAN_START_STOP event received the state is

*  changed to the CYBLE_STATE_SCANNING. When CyBle_GapcConnectDevice() API is

*  called the state is changed to CYBLE_STATE_CONNECTING. After successfully

*  connection indicated by CYBLE_EVT_GAP_DEVICE_CONNECTED or

*  CYBLE_EVT_GAP_ENHANCE_CONN_COMPLETE event the state is changed to

*  CYBLE_STATE_CONNECTED. If CyBle_GapDisconnect() API is called and

*  EVT_GAP_DEVICE_DISCONNECTED event received the state is changed to the

*  CYBLE_STATE_DISCONNECTED. If CyBle_Stop() API is called state of component

*  is changed to the CYBLE_STATE_STOPPED.

*

* \return

*  CYBLE_STATE_T: The current state.

*   * CYBLE_STATE_STOPPED       - BLE is turned off

*   * CYBLE_STATE_INITIALIZING, - Initializing state

*   * CYBLE_STATE_CONNECTED     - Peer device is connected

*   * CYBLE_STATE_ADVERTISING   - Advertising process

*   * CYBLE_STATE_SCANNING      - Scanning process

*   * CYBLE_STATE_CONNECTING    - Connecting

*   * CYBLE_STATE_DISCONNECTED  - Essentially idle state

*

******************************************************************************/

Using that, you can compare it with states that you don't want it in to reset the BLE state/unit.

CyBle_Stop() Will shut down the BLE subsystem, and then you can re-call CyBle_Start() afterwards to essentially restart the BLE subsystem.

However, if you are correctly handling the states of your program code and structure/architecture, then you should be able to account for every possibility and to just go to the next step of your program without having the hardware freeze or cause issues.

It could be you are: Mishandling function calls to the BLE radio; Missing an error/event that you need to handle; Your code is crashing/has bugs; The hardware has some issues/flaws; Etc. You would need to give more information/upload your project for us to be able to help out more specifically.

0 Likes

I don't think I was clear, so let me list the order of operations:

  1. Start as a Peripheral and advertise
  2. Receive a message, switch to Central
  3. Push messages to other peripherals (mesh network)
  4. Change roles to being a peripheral again
  5. Start Advertising

However, i'm getting stuck in Central, item 2 or 3 (most likely 3)

In my header file I have defined :

#define BLE_PERIPHERAL   1

#define BLE_CENTRAL         2

In my C file:

uint8 ble_gap_state = BLE_PERIPHERAL;

Basically, I have it set up so I can check witch role my device is assuming by calling this variable, and it shows every so often that it is not moving out of BLE_CENTRAL.

I have one project that works PERFECT, every time, and another project using (nearly) the same code that has this issue. I am using different BLE modules. The successful project is using the CY8C4248LQI-BL583, which came with the KitProg, and my failing project is using the CYBLE-202007-01.

From what you just said, I now think my project with the 202007-01 may not be working due to radio issues. Like I mentioned, the other project works perfectly, so it isn't a matter of handling my states incorrectly. To be sure, I sent 60 messages through a mesh composed of the CY8C4248LQI-BL583 dev boards flawlessly.

In fact, one thing that I just noticed is that Adv/Scan TX Power Level and Connection TX Power Level, in the BLE Component, were both set to 3 dBm. Documentation states they should be at -12 dBm.

I'll go do some testing and get back with you. Thanks!

0 Likes
Anonymous
Not applicable

Some of the radios have tricky interactions/timings, so the radio could very well be the source of the problem.

Thanks for clearing up the confusion with more explanation; If you have some more radios/modules you could try a third/fourth radio module and see if it fails on other radio modules, or if just the 202007-01 fails.

The TX Power level should only be configurable in allowable ranges for the radio, but testing it doesn't take long I suppose.

Another thing you could try is modifying connection settings/radio settings to see if it affects the performance, but that would be trial and error for the most part 😕

Not that I think the code could be the problem, but if the code is "nearly" the same, then there are still differences that could be causing the difference in behavior

If you can debug more variables than just the BLE_CENTRAL value, seeing what settings the BLESS variables are set to when the device screws up could be useful in diagnostics/debug as well.

0 Likes