I am using a CYBLE-222014-01 as a central device and a second CYBLE-222014-1 as a peripheral device in a two product system I designed. Upon power up of both devices, the central device will automatically pair with peripheral. When idle, both devices go into sleep mode to reserve battery. Internally, the BLE stack wakes the devices up and checks connection. Not sure how this is really happening but it does. The central device also can be woken up by pressing one of three switches. When anyone of these switches is pressed, it writes to the associated characteristic and the peripheral will respond as programmed.
Here is the problem which is becoming a customer nightmare. The both devices rely heavily on detecting that the BLE connection status. If the connection should break, the central needs to start scanning again and the peripheral needs to advertise. In 99% of the time, this works perfectly. The other 1% of the time, the peripheral detects a broken connection and goes into advertising mode however, the central device doesnt detect the disconnect and operates as if it is still connected. In once instance, with the peripheral powered off, the central device detected the disconnect and immediately reconnected but there was no peripheral to connect to.
I have place a function processEvents frequently throughout the central firmware to call the General Handler for the BLE to process change of states. I also just recently added a function to manually read the state CYBLE_GetState() to check for disconnect. Neither appear to help the situation
I have used another BLE module in the past and they had a similar bug in their BLE stack which would not always detect a disconnection.
At this point I am at a loss as to what could be wrong since it works 99% of the time. The 1% that does work is problematic in the use of this device system.
Unfortunately I cant post any code as it is proprietary. I would like to know if this has been seen elsewhere and what is the fix.
I also would like to know what the function call would be to force a disconnect either by central or peripheral.
Finally, I need better clarity as to how the connection interval setting works from both perspective central and peripheral. I find the data sheet very vague and not clear as to how to set a value for this interval.
Anyone responding to this post, please do not ask for code, I cant send it. Also, dont just send me a link to the datasheets, been over them more than I care to admit. I am looking for real answers. If you are referencing a datasheet, then give specifics as to what part of that datasheet will help me and why. If you have sample code, please explain why it pertains to this issue.
Thanks and Regards,
Thank you for the response.
1. This issue has been around for some time and have posted in the forum about it several times. One of the initial replies were regarding setting the ECo capacitance. I followed the specifications to set this value for my particular model. For whatever reason, it made the overall connection process unstable which wasnt even my problem. I can undertsand the reasoning to fine tune the frequency, but from a logi point of view, it doesnt make sense why this setting would affect the BLE detecting a disconnect 1% of the time and work perfectly 99% of the time. Without touching the ECO and if not for this 1% issue, the module works flawlessly in at least 1000 products sold. If I am missing something here, please advise.
2. I will look at these functions since it looks like I will have to create an alternate heart beat function if I cant get a reasonable solution to why my issue is happening. Do you have any code examples of these in use, especially from client perspective?
3. I understand how connection interval is set. Is this the setting that wakes the BLE up out of sleep mode to verify it is still connected to the other device? What happens behind the scene? Both central and peripheral go into low power mode. What triggers a wakeup to verify the devices are connected? See code snippet below which is used for both devices.
Settings for both devices
Central device (Connection Supervision - 5000mS, connection interval 7.5ms min 50mS max, slave latency 0)
Peripheral device (Connection Supervision - 10000mS, connection interval 1000ms min 1000mS max, slave latency 0)
Sleep mode Function for both devices
/* Local variable to store the status of BLESS Hardware block */
/* Put BLESS into Deep Sleep and check the return status */
sleepMode = CyBle_EnterLPM(CYBLE_BLESS_DEEPSLEEP);
/* Disable global interrupt to prevent changes from any other interrupt ISR */
/* Check the Status of BLESS */
blessState = CyBle_GetBleSsState();
if(sleepMode == CYBLE_BLESS_DEEPSLEEP)
/* If the ECO has started or the BLESS can go to Deep Sleep, then place CPU
* to Deep Sleep */
if((blessState == CYBLE_BLESS_STATE_ECO_ON || blessState == CYBLE_BLESS_STATE_DEEPSLEEP)&& (CyBle_GetState() != CYBLE_STATE_DISCONNECTED))
if(blessState != CYBLE_BLESS_STATE_EVENT_CLOSE)
/* If the BLESS hardware block cannot go to Deep Sleep and BLE Event has not
* closed yet, then place CPU to Sleep */
Other than the ECO setting, what triggers the verification that both are connected, how is it determined they are connected, when is the flag set and how is it processed. I am checking the event handler quite often so if the disconnect is set, it should be processed. To reiterate, this process works 99% of the time but randomly it doesnt.
Thanks and Regards,
I have added many ProcessEvent checks throughout the program many months ago. All the information you have sent is helpful but not addressing the core question, why when it looses connection doest it still think it is connected when I have many processEvent checks as well as a manual check for BleState? If the state doesnt change, interrupts and manual testing will always fail to identify a disconnect.
I am also still looking for the behind the scene process explanation as to how the stack works to verify the devices are connected especially in sleep mode. I still feel there is a bug in the stack since I have seen this same condition in another manufacturers device, also with a very random time it occurs.
We are checking our database internally to identify if these kind of issues happened before.
This response doesn't answers your questions but it will be useful to reduce the frequency of the issue:
1. Put the connection max and min interval to 7.5 milli seconds at the Central side.
2. Ensure the BLE interrupt is configured to highest priority in both Central and Peripheral devices.
3. Ensure that you have followed the firmware flow used in the PSOC 4 BLE low power code example given in the link below:
4. Ensure that you are using latest versions of cy_boot component(5.90) and BLE components(BLE v 3.65) in your application.
5. If possible please do the "Attach to running target" and see the call stack. This might help you in identifying the issue.
6. When peripheral or central disconnects, please check the disconnection reason that comes along with DISCONNECTED event and let us know.
Thank you for your response.
1. I will update min and max interval time to 7.5mS
2. When this problem first started, I did move BLE priority to highest but it didnt resolve problem.
3. I will read through this document which I believe I followed already but will verify.
4. BLE module was updated to V3.65 on both sides a few months ago. It didnt resolve issue either. I am not sure of what you mean by cy_boot components. I do not have any bootloader modules installed.
5. Unfortunately, this is not feasible to do. Since the problem is random and occurs in finished units, I have not been able to have the devices connected to Psoc Creator to investigate when problem occurs.
6. Same as #5
I am still hoping someone can explain how the two devices remain connected in low power mode. What happens behind the scenes? Maybe once I know how this works I can possible understand what is causing my issue.
Could you please reduce the connection supervision timeout to minimum possible value? It's range is from 100ms to 32000ms.
Please note, for proper operation the Connection Supervision Timeout must be larger than ((1 + Slave latency) * Connection Interval * 2 (ms)).
Reducing connection supervision timeout value will enable central to detect disconnections faster.
Thanks and Regards,