Ble connection stops working after 'Max num. of ble connections' times

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

cross mob
Anonymous
Not applicable

To preface, we are using Cy Ble Dongle for debugging purposes and our BLE PDL is set as GAP peripheral.

We are experiencing unusual behavior with ble connection where after 4 successive connections, the peripheral fails to connect to central on next attempt. After failing to connect for 4 times, ble connection connects successfully again for another 4 connections, and the cycle repeats. We suspect it is because 'Maximum number of BLE connections' is set to 4 for our BLE PDL. But it is unusual that this would occur since we are connecting using the same device (Cy Ble Dongle) on all connections so the peripheral should not detect the connections as different device connections. Has anyone observed the same behavior and what fixed the problem?

Note: we've also changed 'Maximum number of BLE connections' to 2, and observe the similar behavior where it succeeds to connect for 2 attempts, fails for 2 attempts, succeeds for 2 attempts, and the cycle repeats.

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hello ssl.huynh_3143771​,

It appears like we were missing to call the callback on certain events and that seem to not trigger the callback required to call ProcessEvents.

The fix is to add the events to the BLE interrupt handler defined in cy_ble_hal_int.c file. I am attaching the fixed/updated file - can you try and let me know if that helps?

Also note that the issue does not exist in dual-core mode, so if you use dual-core mode then the issue should go away as well without the fix.

This fix will be available in a future release of the BLE PDL.

Regards,

Meenakshi Sundaram R

View solution in original post

0 Likes
20 Replies
himam_31
Employee
Employee
50 likes received 25 likes received 10 likes received

Hello,

1)Can you attach the project?

2)Can you try connecting to a different BLE Central? Like mobile CySmart or something else and check if you face an issue?

Thanks,

Hima

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi hima,

I've attached our project to this comment. We've tried connecting using the CySmart App and the problem persists. Could you run our code and see if you experience the same issue? We notice that calling Cy_BLE_ProcessEvents inside the infinite for-loop fixes the issue but we are trying to minimize the number of times that Cy_BLE_ProcessEvents API gets called to conserve power.

Also during advertisement deep sleep alternates between successfully and failing to enter deep sleep mode. We are unsure if this is normal behavior because of the rapidity that deep sleep gets called.

0 Likes

Hello,

I have tested the project. I'm able to connect to CySmart multiple times when I'm pressing the wake up switch SW2. However I'm not able to pair to the device. The pairing request is always failing. I think pairing is not taken care in the firmware.

Thanks,

hima

0 Likes
Anonymous
Not applicable

Hi hima,

We are still only able to successfully connect every other connection.

Could you elaborate on how you're unable to pair the device and how you're checking for this?

Also, we notice that putting Cy_BLE_ProcessEvents() inside the infinite for-loop fixes the issue, but we are trying to conserve the number of times the API gets called which is why we attached a callback function to the bless interrupt that calls Cy_BLE_ProcessEvents() on each interrupt trigger.

0 Likes

Hello ssl.huynh_3143771​,

I was able to notice the same behavior in your project and have raised an internal ticket to involve our component and stack team to debug the issue. I will keep you updated on the issue.

Another note, I was able to successfully pair/connect, if I advertise always i.e. after disconnection I advertise immediately. Can you confirm this behavior as well? And in the project you attached, I did not see any code for pairing and bonding but you had enabled them in your component configuration. Please remember to add required code for pairing and bonding for proper working of the project.

Regards,

Meenakshi Sundaram R

0 Likes
lock attach
Attachments are accessible only for community members.

Hello ssl.huynh_3143771​,

It appears like we were missing to call the callback on certain events and that seem to not trigger the callback required to call ProcessEvents.

The fix is to add the events to the BLE interrupt handler defined in cy_ble_hal_int.c file. I am attaching the fixed/updated file - can you try and let me know if that helps?

Also note that the issue does not exist in dual-core mode, so if you use dual-core mode then the issue should go away as well without the fix.

This fix will be available in a future release of the BLE PDL.

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi msur,

Thank you very much! This solved our issue perfectly.

But we did notice a different problem regarding ProcessEvents. We noticed when Bluetooth is not advertising and a device is not connected (let's call it stale state), ProcessEvents still needs to be called in order for deep sleep functionality to work. Because the bless interrupt does not trigger while Bluetooth is in stale state, we are having to call ProcessEvents indefinitely so long as Bluetooth is in this state. Is there a work-around to this because we would like reduce the number of calls to ProcessEvents as much as possible? Also, please let me know if I should begin a new thread for this question. Thank you.

Best,

Steve

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Steve,

You will need to do a bit more logic to call the ProcessEvents, then just relying on the interrupt to call it.

The below logic is what I usually use in my code for calling ProcessEvents -

if(processEvents || (!isStackOn) || (!isStartAdvComplete))

    {

        Cy_BLE_ProcessEvents();

      

        processEvents = false;      

    }

I set the processEvents flag in the interrupt callback. I set the isStackOn flag in CY_BLE_EVT_STACK_ON event. I set the isStartAdvComplete flag in CY_BLE_EVT_GAPP_ADVERTISEMENT_START_STOP event. The isStartAdvComplete flag is by default set and cleared after I call Cy_BLE_GAPP_StartAdvertisement. The isStackOn flag is by default cleared and reset every time you Shutdown/stop the BLE component.

In addition, whenever you push data (like notification or write/read responses) to the stack, you will need to call ProcessEvents once at least after the call to the function.

I am attaching a modified version of your project that works without the need to call processEvents when the device is not advertising/connected. Note that you will still need to use the workaround from my previous post in this project.

Let me know if this helps.

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi Meenakshi,

I think you may have forgotten to attach the modified version.

Best,

Steve

0 Likes
lock attach
Attachments are accessible only for community members.

I actually attached but it is not showing in the post. I am attaching again - if it does not show, I will upload in a cloud-drive and share.

0 Likes
Anonymous
Not applicable

Hi Meenakshi,

Thank you for reattaching the project.

I have run your attached project and compared it with the project I initially attached. I noticed that in the stale state, your project successfully remains in deep sleep. While in my project after some time, the core wakes up and fails to ever reenter deep sleep. Could you let me know if you notice the same observations? Because if the core successfully remains in deep sleep, it seems that ProcessEvents doesn't need to be called before going to deep sleep.

Best,

Steve

0 Likes

Hello Steve,

Yes I confirm the behavior i.e. if I make the "if" condition as always false, the device never enters DeepSleep. The reason is because the controller did not get sufficient ProcessEvents calls to turn ON. As a result, the DeepSleep callback attached by the BLE to the Cy_SysPm_DeepSleep API never lets the system enter DeepSleep.

This is where isStackOn implementation I mentioned earlier helps.

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi msur,

Were any changes made to the project other than the firmware and cy_ble_hal_int.c file? It's unusual that copying and pasting verbatim your firmware code into our project gives the same issue, where the core wakes up intermittently from deep sleep on its own. Where as it remains in deep sleep in the project that you've provided.

Best,

Steve

0 Likes

Steve,

Can you attach your project again? As I mentioned, the project you attached did not work/connect for me (I was using iPhone) as that project was not handling certain BLE events required for authentication/encryption. So I had to add few additional events to the EventHandler. Also, I had disabled bonding in the component configuration, as the project did not have code to handle bonding as well.

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi msur,

After some trial and error we notice that disabling in the Bluetooth GUI: Link Layer Settings -> Enable Link Layer Privacy, that doing so fixes the issue. The core no longer wakes up periodically on its own while in stale state. Could you let us know if this normal behavior or a possible bug in the internal code?

Best,

Steve

0 Likes

Hello Steve,

I need to take a look at the example again and should be able to get back next week only. Will let you know what I notice and why (if I notice the same issue) by Monday/Tuesday next week. As I cannot tell anything regarding this issue from top of my head

Regards,

Meenakshi Sundaram R

0 Likes

Hello Steve,

I took a look at the issue. I am not sure if what I am seeing the same issue you are talking about. What I see is that when the device/BLESS is idle, after around 40 seconds, the device comes out of DeepSleep and never enters DeepSleep.

On debugging, I saw that the BLESS does not enter DeepSleep mode and as a result, the Cy_SysPm_DeepSleep API does not let the CPU enter DeepSleep. I noticed that calling ProcessEvents when this situation happens, solves the issue.

Can you add the below condition as well for calling ProcessEvents?

if(processEvents || (!isStackOn) || (!isStartAdvComplete) || (CY_BLE_BLESS_STATE_EVENT_CLOSE == Cy_BLE_StackGetBleSsState()))

    {

        Cy_BLE_ProcessEvents();

       

        processEvents = false;       

    }

I am checking with our stack and component team if this is a known issue or not. I will update you once I hear back from them. Meanwhile, if you can try this out and let me know the results at your end, it will be great.

Regards,

Meenakshi Sundaram R

0 Likes
lock attach
Attachments are accessible only for community members.

Steve,

I had a discussion with our stack team and the reason for the failure in my case was a generic timer expiry (interrupt - around 40 seconds if no BLE activity), which needs to be processed by the stack. Currently, this event is not passed to the callback.

I am attaching (another quick-fix) version of cy_ble_hal_int.c file that has this issue fixed. As I mentioned, I am not sure if we are seeing the same issue. Can you try the attached file and see if it helps.

This works in my project with/without Privacy.

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi msur,

We are also experiencing the device wake up when the device/BLE is idle. However, we notice that if we change the if-condition so that ProcessEvents gets called after the wake up, then it can successfully go back to sleep. A little bit later while the device/BLE is idle, it will wake up again and the sleep-wakeup-ProcessEvents cycle repeats.

We've also used the modified cy_ble_hal_int.c file that you recently attached and it fixes the issue. We notice that it is essentially doing as what we described above. We are wondering if the generic timer expiry that causes the device to wake up is normal behavior then, because the wake up doesn't happen we we disable the Link Layer Privacy.

Best,

Steve

0 Likes

Hello Steve,

Yes that is an expected behavior. We need to process certain items in the BLESS at least every 40 s, if it is enabled.

We will be merging all these fixes in the next release of the PDL.

Regards,

Meenakshi Sundaram R

0 Likes