Setting Cores to Deep Sleep Mode while BLE Function is Enabled on PSoC® 6 – KBA223291

Version: **



How does the performance of Arm® Cortex®-M4 and Cortex-M0+ differ when a BLE stack is allocated on dual cores and on a single CM0+ while the cores are in Deep Sleep mode initiated by the Cy_SysPm_DeepSleep() API?



Consider project CE212736 as an example.

The original setting allocates BLE stack on both CM4 and CM0+. When the Cy_SysPm_DeepSleep() API is called, CM4 is set to Deep Sleep mode when BLE state is advertising or connected, and does not wake up until the next BLE stack event generated.

If the project is modified to use a single cm0+ with cm4 disabled, performance of cm0+ would be different when the same API Cy_SysPm_DeepSleep() is called. Cm0+ can also enter Deep Sleep mode, but will not wake up immediately. If BLE state is advertising, the Deep Sleep timing is around the advertising interval; if BLE state is connected, the Deep Sleep timing is around the connection interval (default slave latency is 0).

The differences are caused by the BLE Subsystem (BLESS) interrupt allocated on cm0+. BLESS interrupt must be allocated on the BLE controller part. If the entire BLE stack is placed on cm0+, BLESS interrupt would always wake up cm0+ from Deep Sleep. But, if the BLE controller is placed on CM0+ and the host is placed on CM4, then CM4 is separated and does not wake up with the BLESS interrupt and continues to stay in Deep Sleep mode until the next BLE stack event is generated.