You are here

BLE and DeepSleep problem | Cypress Semiconductor

BLE and DeepSleep problem

Summary: 6 Replies, Latest post by gfavaro on 15 Sep 2016 02:06 AM PDT
Verified Answers: 0
Last post
Log in to post new comments.
andreas.ak2_1499391's picture
16 posts


I have a very big problem with DeepSleep in my project.

I use the CY8CKIT-042-BLE with the CY8CKIT-043A device. I have a very big project with an SPI-RTC, an SPI-LCD-Display, an adc, an Op-Amp, a timer, a reset-watchdog and of course the BLE-Component.

The RTC generates an interrupt each second and triggers the adc to do a measurement. Beside that a timer-component generates a 40ms-Interrupt for the handling of the BLE. Thats o.k. It works perfect if I use the "Sleep" mode.

I used the Global-Signal component with the "AllPortInt" and a custom ISR to wake up the device from the GPIO-Interrupt from the external RTC.

If I try to use the "DeepSleep" according to the example, I see that the device wakes up one time and then it is stuck in an endless loop. In the picture I added you see that the DeepSleep is entered (first signal goes low). It is interrupted by the BLE-component for some milliseconds. But if the RTC triggers (falling edge) the DeepSleep is left and never entered again. At 5.5s it looks like the AllPortInt triggers again, but I don't know why. I clear the interrupt in the ISR by calling _ClearPending() in both, the single GPIO-ISR and the AllPortInt-ISR.
This is the call stack from this situation:

0 CySysPmSleep() .\Generated_Source\PSoC4\cyPm.c 52 0x0000874A (All)
1 ll_exit_low_power_mode() ?????? ?????? 0x0000DC06 (All)
2 ll_task_handler() ?????? ?????? 0x000112C8 (All)
3 llft_service_queue() ?????? ?????? 0x00011AAE (All)
4 llf_task_start_routine() ?????? ?????? 0x00011A06 (All)
5 CyBle_StackTaskHandler() ?????? ?????? 0x0000C3E6 (All)
6 OS_scheduler() ?????? ?????? 0x0000D276 (All)
7 CyBleStackMgr_ProcessBleEvents() ?????? ?????? 0x0000C116 (All)
8 CyBle_ProcessEvents() ?????? ?????? 0x0000BE38 (All)
9 main() .\main.c 98 0x00000444 (All)

I have no clue what I should do now?
I hope that anybody can help me!

Thanks Andreas

mady's picture
Cypress Employee
1113 posts


Can you please increase the BLESS Interrupt priority (in the Interrupt Tab in *.cydwr file)?


- Madhu Sudhan

andreas.ak2_1499391's picture
16 posts

The BLE_Bless_IRQ already has the highest priority ("0").

I have a few other interrupts, a timer, some buttons and they have all lower priorities (1-3).


andreas.ak2_1499391's picture
16 posts

After my other project kept crashing in random situations, I set up a new project where I started out with the Deep-Sleep-Examples.

Now I think I found a solution: The I2C-Interrupt must have a higher priority than the BLE-ISR.

I used the SCB_P4_v3.0 component to drive a serial LCD and this component is quite buggy. There are a lot of while-loops with no timeouts. I made myself a copy of this component and fixed the worst bugs, but I obviously forgot some.

As long as I didn't write or read from I2C everything was fine, but when a longer I2C-operation was interrupted by a BLE-Interrupt, both components got stuck! So now I'm not yet sure if it is a bug in the SCB-component and where.

Previously I also tried to use Cy_EnterCriticalSection and Cy_ExitCriticalSection around the I2C-operation, but it didn't stop the BLE-Interrupt from interrupting the I2C. This might also be a bug in the BLE-Component. At least it is something I wouldn't expect!

Maybe this helps others with the same problem!

Best regards

andreas.ak2_1499391's picture
16 posts


Every use of CyEnterCriticalSection and CyExitCriticalSection seems to end in a deadlock with the BLE-component.

Can anybody confirm this?

cjoachim_1597296's picture
75 posts

I had (have?) the problem that CyBle_Stop() hung my program. The call stack from debugging was very similar to your. I fixed (?) the problem with a call to CyBle_ExitLPM() before CyBle_Stop(). Maybe this can be of help to you.

gfavaro's picture
5 posts


i use a LPCOMP and i need to kill BLE to have the minimun comsumption, i confirm that before call Stop BLE is better stop ADV or CONNECTION and exit low power than call stop function.


Log in to post new comments.