Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
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?
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.