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!
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).
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!
Every use of CyEnterCriticalSection and CyExitCriticalSection seems to end in a deadlock with the BLE-component.
Can anybody confirm this?
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_Stop(). Maybe this can be of help to you.
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.