Bluetooth Fails to Advertise While Entering Deep Sleep

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

cross mob
Anonymous
Not applicable

Hi there,

We are having issues with bluetooth advertisement. To preface, we are using single core (cm0+) for Bluetooth, and have registered a callback function for the AppHost using Cy_BLE_RegisterAppHostCallBack() which Processes Events. As suggested in this discussion, Ble connection stops working after 'Max num. of ble connections' times , we have modified the cy_ble_hal_int.c file so that the callback is called during certain events.


Bluetooth can start advertisement, time out, restart, and so on successfully as long as no device has ever been connected. However, after the first connection proceeded by the first disconnection, once advertising times out it fails to restart again. We can confirm it as an issue with the device entering deep sleep while bluetooth is advertising since the issue doesn't occur when we put it into sleep mode instead. Our low-power code is as follows:

for(;;)

{

     if(!Cy_SysPm_Cm0IsLowPower())

    {

        Cy_SysPm_EnterLowPowerMode();

    }

   

    cy_en_ble_bless_state_t bleSsState = Cy_BLE_StackGetBleSsState();

   

    if(bleSsState == CY_BLE_BLESS_STATE_ACTIVE || bleSsState == CY_BLE_BLESS_STATE_ECO_STABLE)

    {

        cy_en_syspm_status_t apiResult = Cy_SysPm_Sleep(CY_SYSPM_WAIT_FOR_INTERRUPT);

    }

    else

    {       

        cy_en_syspm_status_t apiResult = Cy_SysPm_DeepSleep(CY_SYSPM_WAIT_FOR_INTERRUPT);

    }   

}

We are wondering what is the problem? Also, what is the best way to debug and stress test functionalities with deep sleep? In debugger mode, the described problem does not occur because the device does not enter deep sleep as it would during regular programming. Thank you.

1 Solution

Steve,

What I have implemented and recommended to many customers is the below for implementing a callback based BLE application design in an RTOS environment -

1. Run all BLE related calls (Cy_BLE_... API usage) in a single thread and have the thread run at possibly the highest priority. What this means is you will have to implement some message queuing based thread for BLE and process the messages as posted from other tasks. Messages can be for Send Notifications, Authentication input/confirmations etc. One of the message can be the ProcessEvents request from the callback.

2. Now the Callback is from an interrupt and it is a high priority interrupt (Priority '1'). In most RTOSes, a call to a RTOS API like message queue posting or semaphore signaling cannot be made from interrupts above a certain configurable priority (configMAX_API_CALL_INTERRUPT_PRIORITY in FreeRTOS). For this reason, it is recommended to software trigger another lower priority interrupt (configure an IPC interrupt structure for CM4 with interrupt priority below configMAX_API_CALL_INTERRUPT_PRIORITY), and signal the RTOS API from the low priority interrupt. This signal wakes up the BLE thread and lets it call the ProcessEvents.

I am not sure if you are using an OS thread based implementation or referring to functions as threads. But I believe you get the point from the above??

Regards,

Meenakshi Sundaram R

View solution in original post

0 Likes
9 Replies
lock attach
Attachments are accessible only for community members.
MeenakshiR_71
Employee
Employee
100 likes received 50 likes received 25 likes received

Steve,

Are you doing the test with the same project you had from the other post?

I just modified the project with the code you provided and it seem to behave properly. I believe the StartAdvertisement is still through switch press??

Take a look at the attached project and let me know if you are doing anything different. I was not able to observe the issue with the updated cy_ble_hal_int.c file (I provided in the other thread).

Regards,

Meenakshi Sundaram R

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

Hi msur,

We have changed advertising since then so that the device is always in discovery mode if a remote device is not connected. I've attached the project that we are currently testing, could you let us know if you are observing the same issues? Thank you.

0 Likes
Anonymous
Not applicable

Hi msur,

We are still experiencing the same issue. Could you let us know if you are observing the same issue when getting the chance? Thank you.

0 Likes
Anonymous
Not applicable

If anyone is experiencing and observing the same issue, please let us know and we can work together to figure out the issue. Thank you.

0 Likes

Hello Steve,

Sorry for a really late response. I was on a business travel for the past 5-6 weeks.

I just got time to take a look at the code again and I notice that you are have been calling the "Cy_BLE_ProcessEvents" from within the host callback. Please make sure you use a flag and call Cy_BLE_ProcessEvents based on that. The callback is initiated from an interrupt context and Cy_BLE_ProcessEvents is not supposed to or rather designed to execute from an interrupt context.

Having said that, did you try our latest PDL (3.0.4)? We have the full fix as I pointed out in the other thread - https://community.cypress.com/message/164631?et=watches.email.thread#164631.

Let me know if you see the issue even after the above two changes.

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi msur,

No worries at all.

We haven't gotten to trying the latest PDL yet so that may help to fix the issue.

Also we are trying to work around setting a flag for Cy_BLE_ProcessEvents in the main thread to lower power consumption in the long run. Another concern is that other higher priority threads may run and cause pending Bluetooth Events to not be processed soon enough from the main thread, which could cause Buetooth advertising/connectivity issues.

What are your thoughts? Thank you!

Best Regards,

Steve

0 Likes

Steve,

What I have implemented and recommended to many customers is the below for implementing a callback based BLE application design in an RTOS environment -

1. Run all BLE related calls (Cy_BLE_... API usage) in a single thread and have the thread run at possibly the highest priority. What this means is you will have to implement some message queuing based thread for BLE and process the messages as posted from other tasks. Messages can be for Send Notifications, Authentication input/confirmations etc. One of the message can be the ProcessEvents request from the callback.

2. Now the Callback is from an interrupt and it is a high priority interrupt (Priority '1'). In most RTOSes, a call to a RTOS API like message queue posting or semaphore signaling cannot be made from interrupts above a certain configurable priority (configMAX_API_CALL_INTERRUPT_PRIORITY in FreeRTOS). For this reason, it is recommended to software trigger another lower priority interrupt (configure an IPC interrupt structure for CM4 with interrupt priority below configMAX_API_CALL_INTERRUPT_PRIORITY), and signal the RTOS API from the low priority interrupt. This signal wakes up the BLE thread and lets it call the ProcessEvents.

I am not sure if you are using an OS thread based implementation or referring to functions as threads. But I believe you get the point from the above??

Regards,

Meenakshi Sundaram R

0 Likes
Anonymous
Not applicable

Hi Meenakshi,

Sorry for the confusion - we are referring to interrupts as background threads and the main thread as the foreground thread.

Could you elaborate on what is happening underneath that Cy_BLE_ProcessEvents is not recommended to be called from the interrupt context? We'd like to see if there is a workaround without using FreeRTOS.

Also we are new to using FreeRTOS so we will look more into that - is there an example code that describes the message queue you mentioned?

Best,

Steve

0 Likes

Yes, Steve. All our RTOS examples that include BLE use this approach. You can refer to this example for instance - http://www.cypress.com/documentation/code-examples/ce222604-psoc-6-mcu-ble-connectivity-rtc-current-...

0 Likes