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.

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.

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.

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.