SysPm (System Power Management)

group group_syspm

Use the System Power Management (SysPm) driver to change power modes and reduce system power consumption in power sensitive designs.

The functions and other declarations used in this driver are in cy_syspm.h. You can include cy_pdl.h to get access to all functions and declarations in the PDL.

For multi-CPU devices, this library allows you to individually enter low power modes for each CPU.

This document contains the following topics:

  • Power Modes

  • System Power Modes

    • Switching the System into Ultra Low Power

      • ULP Limitations

    • Switching the System into Low Power

      • LP Limitations

    • Switching CPU into Sleep

    • Switching the System or CPU into Deep Sleep

    • Waking Up from Sleep or Deep Sleep

    • Switching System to Hibernate

    • Waking Up from Hibernate

  • System Regulator Current Mode

    • Setting Minimum System Regulator Current Mode

    • Setting Normal System Regulator Current Mode

  • Migration Guide: Moving to SysPm v4.0

  • Managing PMIC

  • Managing the Backup Domain

  • SysPm Callbacks

    • SysPm Callbacks Example

    • Callback Configuration Considerations

      • Callback Function Parameters

      • Callback Function Structure

      • Callback Function Implementation

      • Callbacks Execution Flow

      • Callback Registering

      • Callback Unregistering

  • Definitions

Configuration Considerations

Power Modes

PSoC 6 MCUs support four system and three CPU power modes. These power modes are intended to minimize average power consumption in an application. System power modes:

  • Low Power - All peripheral and CPU power modes are available to be used at maximum device frequency and current consumption.

  • Ultra Low Power - All peripheral and CPU power modes are available, but the frequency and current consumption are limited to a device specific number.

  • Deep Sleep - Device and I/O states is retained. Low-frequency peripherals are available. Both CPUs are in CPU Deep Sleep power mode.

  • Hibernate - The device and I/O states are frozen and the device resets on wakeup.

The CPU Active, Sleep and Deep Sleep power modes are Arm-defined power modes supported by the Arm CPU instruction set architecture (ISA).

System Power Modes

  • LP - In this mode, code is executed and all logic and memories are powered. Firmware may disable/reduce clocks for specific peripherals and power down specific analog power domains.

  • ULP - This power mode is like LP mode, but with clock restrictions and limited/slower peripherals to achieve lower current consumption. Refer to Switching the System into Ultra Low Power in Configuration considerations.

  • Deep Sleep - Is a lower power mode where high-frequency clocks are disabled. Refer to Switching the System or CPU into Deep Sleep in Configuration considerations. Deep-sleep-capable peripherals are available. A normal wakeup from Deep Sleep returns to either system LP or ULP mode, depending on the previous state and programmed behavior for the configured wakeup interrupt. Likewise, a debug wakes up from system Deep Sleep and woken CPU returns to CPU Sleep. Refer to Waking Up from Sleep or Deep Sleep in Configuration considerations.

  • Hibernate - Is the lowest power mode that is entered from firmware. Refer to Switching System to Hibernate in Configuration considerations. On wakeup the CPU(s) and all peripherals go through a full reset. The I/O’s state is frozen so that the output driver state is held in system Hibernate. Note that in this mode, the CPU(s) and all peripherals lose their states, so the system and firmware reboot on a wakeup event. Backup memory (if present) can be used to store limited system state for use on the next reboot. Refer to Waking Up from Hibernate in Configuration considerations.

Switching the System into Low Power

To set system LP mode you need to set LP voltage for the active core regulator:

  • If active core regulator is the LDO, call:

    Cy_SysPm_LdoSetVoltage(CY_SYSPM_LDO_VOLTAGE_LP);
    

  • If active core regulator is the Buck, call:

    Cy_SysPm_BuckSetVoltage1(CY_SYSPM_BUCK_OUT1_VOLTAGE_LP)
    

After switching into system LP mode, the operating frequency and current consumption may now be increased up to LP Limitations. The wait states for flash may be changed to increase device performance by calling SysLib function Cy_SysLib_SetWaitStates(true, hfClkFreqMz), where hfClkFreqMz is the frequency of HfClk0 in MHz.

LP Limitations

When the system is in LP mode, the core regulator voltage is set to 1.1 V (nominal) and the following limitations must be met:

  • The maximum operating frequency for all Clk_HF paths must not exceed 150 MHz*, and peripheral and slow clock must not exceed 100 MHz *

  • The total current consumption must be less than or equal to 250 mA *

warning

* - Numbers shown are approximate and real limit values may be different because they are device specific. You should refer to the device datasheet for exact values of maximum frequency and current in system LP mode.

Switching the System into Ultra Low Power

Before switching into system ULP mode, ensure that the device meets ULP Limitations. Decrease the clock frequencies, and slow or disable peripherals. Also ensure that appropriate wait state values are set for the flash. Flash wait states can be set by calling SysLib function Cy_SysLib_SetWaitStates(true, hfClkFreqMz), where hfClkFreqMz is the frequency of HfClk0 in MHz.

After the ULP Limitations are met and appropriate wait states are set, you must set ULP voltage for the active core regulator:

  • If active core regulator is the LDO Core Voltage Regulator, call Cy_SysPm_LdoSetVoltage(CY_SYSPM_LDO_VOLTAGE_ULP)

  • If active core regulator is the Buck Core Voltage Regulator, then call Cy_SysPm_BuckSetVoltage1(CY_SYSPM_BUCK_OUT1_VOLTAGE_ULP)

ULP Limitations

When the system is in ULP mode the core regulator voltage is set to 0.9 V (nominal) and the following limitations must be meet:

  • The maximum operating frequency for all Clk_HF paths must not exceed 50 MHz *, whereas the peripheral and slow clock must not exceed 25 MHz *.

  • The total current consumption must be less than or equal to 20 mA*

  • the flash write operations are prohibited. The flash works in the Read-only operation. If Write operations are required, you must switch to the system LP mode.

warning

* - Numbers shown are approximate and real limit values may be different because they are device specific. You should refer to the device datasheet for exact values of maximum frequency and current in system ULP mode.

Switching CPU into Sleep

For multi-CPU devices, the Cy_SysPm_CpuEnterSleep() switches only the CPU that calls the function into the CPU Sleep power mode.

All pending interrupts must be cleared before the CPU is put into a Sleep mode, even if they are masked.

The CPU event register can be set in the past, for example, as a result of internal system calls. So an old event can cause the CPU to not enter Sleep mode upon WFE(). Therefore usually the WFE() is used in an idle loop or polling loop as it might or might not cause entering of CPU Sleep mode. If the idle loop or polling loop is not used, then it is recommended to use WFI() instruction.

Switching the System or CPU into Deep Sleep

For multi-CPU devices, the Cy_SysPm_CpuEnterDeepSleep() function switches only the CPU that calls the function into the CPU Deep Sleep power mode. To set the whole system into Deep Sleep power mode, ensure that all CPUs call the Cy_SysPm_CpuEnterDeepSleep() function.

There are situations when the system does not switch into the Deep Sleep power mode immediately after the last CPU calls Cy_SysPm_CpuEnterDeepSleep(). The system will switch into Deep Sleep mode automatically a short time later, after the low power circuits are ready to switch into Deep Sleep. Refer to the Cy_SysPm_CpuEnterDeepSleep() description for more detail.

All pending interrupts must be cleared before the system is put into a Deep Sleep mode, even if they are masked.

The CPU event register can be set in the past, for example, as a result of internal system calls. So an old event can cause the CPU to not enter Deep Sleep mode upon WFE(). Therefore usually the WFE() is used in an idle loop or polling loop as it might or might not cause entering of CPU Deep Sleep mode. If the idle loop or polling loop is not used, then it is recommended to use WFI() instruction.

For single-CPU devices, SysPm functions that return the status of the unsupported CPU always return CY_SYSPM_STATUS_<CPU>_DEEPSLEEP.

Waking Up from Sleep or Deep Sleep

For Arm-based devices, an interrupt is required for the CPU to wake up. For multi-CPU devices, one CPU can wake up the other CPU by sending the event instruction. Use the Cy_SysPm_CpuSendWakeupEvent() function.

Switching System to Hibernate

If you call Cy_SysPm_SystemEnterHibernate() from either CPU, the system will be switched into the Hibernate power mode directly, because there is no handshake between CPUs.

Waking Up from Hibernate

The system can wake up from Hibernate mode by configuring the following wakeup sources:

  • Wakeup pin

  • LP Comparator

  • RTC alarm

  • WDT interrupt

Wakeup is supported from device specific pin(s) with programmable polarity. Additionally, unregulated peripherals can wake the system under some conditions. For example, a low power comparator can wake the system by comparing two external voltages, but does not support comparison to an internally-generated voltage. The backup power domain remains functional, and if present it can schedule an alarm to wake the system from Hibernate using the RTC. Alternatively, the Watchdog Timer (WDT) can be configured to wake-up the system by WDT interrupt. Refer to Cy_SysPm_SetHibernateWakeupSource() for more detail.

System Regulator Current Mode

In addition to system ULP and LP modes, the five different resource power settings can be configured to reduce current consumption:

  1. Linear regulator low power mode. Can be used only if core current is below the LDO regulator LP threshold.

  2. POR/BOD circuit low power mode. Requires compatible power supply stability due to stability increase response time.

  3. Bandgap reference circuits low power mode (turns on Deep Sleep Bandgap). Requires design to accept reduced Vref accuracy. Active ref can be turned off after this feature is enabled.

  4. Reference buffer circuit low power mode. Requires design to accept reduced Vref accuracy.

  5. Current reference circuit low power mode. Require design to accept reduced Iref accuracy.

These five sub features can modify both system LP or ULP modes as they are independent from LP/ULP settings. When all five sub features are set to their low power modes, the system operates in regulator minimum current mode. In regulator minimum current mode, the system current consumption is limited to a device-specific value. Refer to the device datasheet for the exact current consumption value in regulator minimum current mode.

When all five sub features are set to their normal mode, the system operates in regulator normal current mode. When regulator normal current mode is set, the system may operate at device maximum current.

Setting Minimum System Regulator Current Mode

Before setting the regulator minimum current mode ensure that current limits are be met. After current limits are met, call the Cy_SysPm_SystemSetMinRegulatorCurrent() function.

Setting Normal System Regulator Current Mode

To set regulator normal current mode, call the Cy_SysPm_SystemSetNormalRegulatorCurrent() function. After the function call, the current limits can be increased to a maximum current, depending on what system power mode is set: LP or ULP.

Managing PMIC

The SysPm driver also provides an API to configure the internal power management integrated circuit (PMIC) controller for an external PMIC that supplies Vddd. Use the API to enable the internal PMIC controller output that is routed to pmic_wakeup_out pin, and configure the polarity of the PMIC controller input (pmic_wakeup_in) that is used to wake up the PMIC.

The PMIC controller is automatically enabled when:

  • The PMIC is locked by a call to Cy_SysPm_PmicLock()

  • The configured polarity of the PMIC input and the polarity driven to pmic_wakeup_in pin matches.

Because a call to Cy_SysPm_PmicLock() automatically enables the PMIC controller, the PMIC can remain disabled only when it is unlocked. See Cy_SysPm_PmicUnlock() for more detail.

Use Cy_SysPm_PmicIsLocked() to read the current PMIC lock status.

To enable the PMIC, use these functions in this order:

Cy_SysPm_PmicUnlock();
Cy_SysPm_PmicEnable();
Cy_SysPm_PmicLock();

To disable the PMIC controller, unlock the PMIC. Then call Cy_SysPm_PmicDisable() with the inverted value of the current active state of the pmic_wakeup_in pin. For example, assume the current state of the pmic_wakeup_in pin is active low. To disable the PMIC controller, call these functions in this order:

Cy_SysPm_PmicUnlock();
Cy_SysPm_PmicDisable(CY_SYSPM_PMIC_POLARITY_HIGH);
Note that you do not call Cy_SysPm_PmicLock(), because that automatically enables the PMIC.

While disabled, the PMIC controller is automatically enabled when the pmic_wakeup_in pin state is changed into a high state.

To disable the PMIC controller output, call these functions in this order: Cy_SysPm_PmicUnlock(); Cy_SysPm_PmicDisableOutput();

Do not call Cy_SysPm_PmicLock() (which automatically enables the PMIC controller output).

When disabled, the PMIC controller output is enabled when the PMIC is locked, or by calling Cy_SysPm_PmicEnableOutput().

Managing the Backup Domain

The SysPm driver provide functions to:

  • Configure Supercapacitor charging

  • Select power supply source (Vbackup or Vddd) for Vddbackup

  • Measure Vddbackup using the ADC

Refer to the Backup Domain functions for more detail.

SysPm Callbacks

The SysPm driver handles low power callbacks declared in the application.

If there are no callbacks registered, the device executes the power mode transition. However, frequently your application firmware must make modifications for low power mode. For example, you may need to disable a peripheral, or ensure that a message is not being transmitted or received.

To enable this, the SysPm driver implements a callback mechanism. When a lower power mode transition is about to take place (either entering or exiting System Power Modes), the registered callbacks for that transition are called.

The SysPm driver organizes all the callbacks into a linked list. While entering a low power mode, SysPm goes through that linked list from first to last, executing the callbacks one after another. While exiting low power mode, SysPm goes through that linked list again, but in the opposite direction from last to first. This ordering supports prioritization of callbacks relative to the transition event.

For example, the picture below shows three callback structures organized into a linked list: myDeepSleep1, myDeepSleep2, myDeepSleep3 (represented with the cy_stc_syspm_callback_t configuration structure). Each structure contains, among other fields, the address of the callback function. The code snippets below set this up so that myDeepSleep1 is called first when entering the low power mode. This also means that myDeepSleep1 will be the last one to execute when exiting the low power mode.

The callback structures after registration: ../../../_images/syspm_register_eq.png

Your application must register each callback, so that SysPm can execute it. Upon registration, the linked list is built by the SysPm driver. Notice the &myDeepSleep1 address in the myDeepSleep1 cy_stc_syspm_callback_t structure. This is filled in by the SysPm driver, when you register myDeepSleep1. The cy_stc_syspm_callback_t.order element defines the order of their execution by the SysPm driver. Call Cy_SysPm_RegisterCallback() to register each callback function.

A callback function is typically associated with a particular driver that handles the peripheral. So the callback mechanism enables a peripheral to prepare for a low power mode (for instance, shutting down the analog part); or to perform tasks while exiting a low power mode (like enabling the analog part again).

With the callback mechanism you can prevent switching into a low power mode if a peripheral is not ready. For example, driver X is in the process of receiving a message. In the callback function implementation simply return CY_SYSPM_FAIL in a response to CY_SYSPM_CHECK_READY.

If success is returned while executing a callback, the SysPm driver calls the next callback and so on to the end of the list. If at some point a callback returns CY_SYSPM_FAIL in response to the CY_SYSPM_CHECK_READY step, all the callbacks that have already executed are executed in reverse order, with the CY_SYSPM_CHECK_FAIL mode parameter. This allows each callback to know that entering the low power mode has failed. The callback can then undo whatever it did to prepare for low power mode, if required. For example, if the driver X callback shut down the analog part, it can re-enable the analog part.

Let’s switch to an example explaining the implementation, setup, and registration of three callbacks (myDeepSleep1, myDeepSleep2, myDeepSleep2) in the application. The Callback Configuration Considerations are provided after the SysPm Callbacks Example.

SysPm Callbacks Example

The following code snippets demonstrate how use the SysPm callbacks mechanism. We will build the prototype for an application that registers three callback functions:

  1. myDeepSleep1 - Handles CPU Deep Sleep.

  2. myDeepSleep2 - Handles CPU Deep Sleep and is associated with peripheral HW1_address (see PDL Design section to learn about the base hardware address).

  3. myDeepSleep3 - Handles entering and exiting system Deep Sleep and is associated with peripheral HW2_address.

We set things up so that the myDeepSleep1 and myDeepSleep2 callbacks do nothing while entering the low power mode (skip on CY_SYSPM_SKIP_BEFORE_TRANSITION - see Callback Function Implementation in Callback Configuration Considerations). Skipping the actions while entering low power might be useful if you need to save time while switching low power modes. This is because the callback function with a skipped mode is not even called avoiding the call and return overhead.

Let’s first declare the callback functions. Each gets the pointer to the cy_stc_syspm_callback_params_t structure as the argument.

/* Scenario: There is a need to have three callbacks for the CPU Deep Sleep 
*  mode. DeepSleepFunc1 and DeepSleepFunc2 callback function skip 
*  CY_SYSPM_BEFORE_TRANSITION mode.
*  DeepSleepFunc3 executes all four modes. 
*  Note that for the multi-CPU devices the another CPU must be in CPU 
*  Deep Sleep power mode. 
*/

/******************************************************************************
*  Callback prototypes
******************************************************************************/
cy_en_syspm_status_t DeepSleepFunc1(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode);
cy_en_syspm_status_t DeepSleepFunc2(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode);
cy_en_syspm_status_t DeepSleepFunc3(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode);
Now we setup the cy_stc_syspm_callback_params_t structures that we will pass to the callback functions. Note that for the myDeepSleep2 and myDeepSleep3 callbacks we also pass pointers to the peripherals related to that callback (see PDL Design section to learn about base hardware addresses). The configuration considerations related to this structure are described in Callback Function Parameters in Callback Configuration Considerations.

/******************************************************************************
*  Parameter structures for callback functions
******************************************************************************/
cy_stc_syspm_callback_params_t deepSleepParam1 = 
{
    NULL,
    NULL
};

cy_stc_syspm_callback_params_t deepSleepParam2 = 
{
    &HW1_address,
    &context
};

cy_stc_syspm_callback_params_t deepSleepParam3 = 
{
    &HW2_address,
    NULL
};
Now we setup the actual callback configuration structures. Each of these contains, among the other fields, the address of the cy_stc_syspm_callback_params_t we just set up. We will use the callback configuration structures later in the code to register the callbacks in the SysPm driver. Again, we set things up so that the myDeepSleep1 and myDeepSleep2 callbacks do nothing while entering the low power mode (skip on CY_SYSPM_SKIP_BEFORE_TRANSITION) - see Callback Function Implementation in Callback Configuration Considerations.

/******************************************************************************
*  Callbacks structures
******************************************************************************/
cy_stc_syspm_callback_t myDeepSleep1 = 
{
    &DeepSleepFunc1, 
    CY_SYSPM_DEEPSLEEP,
    CY_SYSPM_SKIP_BEFORE_TRANSITION,
    &deepSleepParam1,
    NULL,
    NULL,
    0
};

cy_stc_syspm_callback_t myDeepSleep2 = 
{
    &DeepSleepFunc2, 
    CY_SYSPM_DEEPSLEEP,
    CY_SYSPM_SKIP_BEFORE_TRANSITION,
    &deepSleepParam2,
    NULL,
    NULL,
    0
};

cy_stc_syspm_callback_t myDeepSleep3 = 
{
    &DeepSleepFunc3, 
    CY_SYSPM_DEEPSLEEP,
    0U,
    &deepSleepParam3,
    NULL,
    NULL,
    0
};
    
Note that in each case the last two fields are NULL. These are fields used by the SysPm driver to set up the linked list of callback functions.

The callback structures are now defined and allocated in the user’s memory space: ../../../_images/syspm_before_registration.png

Now we implement the callback functions. See Callback Function Implementation in Callback Configuration Considerations for the instructions on how the callback functions should be implemented.

/******************************************************************************
*  DeepSleepFunc1 implementation
******************************************************************************/
cy_en_syspm_status_t DeepSleepFunc1(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode)
{
    cy_en_syspm_status_t retVal = CY_SYSPM_FAIL;
    
    
    if (callbackParams != NULL)
    {
        /* In this use case we do not need to use HW address or context
        * So, need to add code to some switch case with callbackParams to avoid 
        * compiler warnings
        */
    }
    
    switch(mode)
    {
        /* In this case ensure that firmware/hardware is ready for CPU
        *  Deep Sleep mode */
        case CY_SYSPM_CHECK_READY:
            if(true/* system is ready */)
            {
                /* Process the "check ready" condition */
                retVal = CY_SYSPM_SUCCESS;
            }
            break;
        
        /* One of the registered callback that was executed after this callback 
        *  returned CY_SYSPM_FAIL, need to revert changes (if any) performed in 
        *  the CY_SYSPM_CHECK_READY case.
        */
        case CY_SYSPM_CHECK_FAIL:
            {
                /* Revert changes done in the CY_SYSPM_CHECK_READY case */
                retVal = CY_SYSPM_SUCCESS;
            }
            break;
            
        /* This case will be skipped during callbacks execution */
        case CY_SYSPM_BEFORE_TRANSITION:
            break;
            
        /* This case is executed after wakeup from system Deep Sleep */
        case CY_SYSPM_AFTER_TRANSITION:
            {
                /* Perform actions, if required, after wakeup from the  
                *  system Deep Sleep mode */
                retVal = CY_SYSPM_SUCCESS;
            }
            break;
        
        default:
            break;
    }
    
    return (retVal);
}


/******************************************************************************
*  DeepSleepFunc2 implementation
******************************************************************************/
cy_en_syspm_status_t DeepSleepFunc2(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode)
{
    CySCB_Type *hwBase = (CySCB_Type *) callbackParams->base;
    cy_stc_scb_spi_context_t *context = (cy_stc_scb_spi_context_t *) callbackParams->context;
    
    cy_en_syspm_status_t retVal = CY_SYSPM_FAIL;

    switch(mode)
    {
        /* Check is the HW1 ready to enter CPU Deep Sleep */
        case CY_SYSPM_CHECK_READY:
        {
            /* ... */
            if (0UL == (CY_SCB_SPI_TRANSFER_ACTIVE & Cy_SCB_SPI_GetTransferStatus(hwBase, context)))
            {
                /* There are no active actions so we can enter CPU Deep Sleep */
                retVal = CY_SYSPM_SUCCESS;
            }
            break;
        }

        default:
            retVal = CY_SYSPM_FAIL;
            break;
    }
    
    return (retVal);
}

    
/******************************************************************************
*  DeepSleepFunc3 implementation
******************************************************************************/
cy_en_syspm_status_t DeepSleepFunc3(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode)
{
    CySCB_Type *hwBase = (CySCB_Type *) callbackParams->base;

    cy_en_syspm_status_t retVal = CY_SYSPM_FAIL;

    switch(mode)
    {
        /* Check is the HW2 ready to enter into CPU Deep Sleep */
        case CY_SYSPM_CHECK_READY:
        {
            if (!Cy_SCB_SPI_IsBusBusy(hwBase))
            {
                /* Process the "check ready" condition */
                retVal = CY_SYSPM_SUCCESS;
            }
        
            break;
        }

        case CY_SYSPM_BEFORE_TRANSITION:
        {
            /* Switch - Turn off SCB SPI */
            retVal = CY_SYSPM_SUCCESS;
            break;
        }
        
        
        case CY_SYSPM_AFTER_TRANSITION:
        {
            /* Switch - Turn on SCB SPI */
            retVal = CY_SYSPM_SUCCESS;
            break;
        }

        case CY_SYSPM_CHECK_FAIL:
        {
            /* Revert changes made in CY_SYSPM_CHECK_READY switch case (if any) */
            break;
        }

        default:
            break;
    }
    
    return (retVal);
}
Finally, we register the callbacks so that the SysPm driver knows about them. The order in which the callbacks will be called depends upon the order in which the callbacks are registered. If there are no callbacks registered, the device just executes the power mode transition.

Callbacks that reconfigure global resources, such as clock frequencies, should be registered last. They then modify global resources as the final step before entering the low power mode, and restore those resources first, as the system returns from low power mode.

    /* Register myDeepSleep1 */
    if (true != Cy_SysPm_RegisterCallback(&myDeepSleep1))
    {
        /* Insert error handling */
    }
    
    /* Register myDeepSleep2 */
    if (true != Cy_SysPm_RegisterCallback(&myDeepSleep2))
    {
        /* Insert error handling */
    }
    
    /* Register myDeepSleep3 */
    if (true != Cy_SysPm_RegisterCallback(&myDeepSleep3))
    {
        /* Insert error handling */
    }
We are done configuring three callbacks. Now the SysPm driver will execute the callbacks appropriately whenever there is a call to a power mode transition function: Cy_SysPm_CpuEnterSleep(), Cy_SysPm_CpuEnterDeepSleep(), Cy_SysPm_SystemEnterUlp(), Cy_SysPm_SystemEnterLp(), and Cy_SysPm_SystemEnterHibernate().

note

On a wakeup from hibernate the device goes through a reset, so the callbacks with CY_SYSPM_AFTER_TRANSITION are not executed. Refer to Cy_SysPm_SystemEnterHibernate() for more detail.

Refer to

Callback Unregistering in Callback Configuration Considerations to learn what to do if you need to remove the callback from the linked list. You might want to unregister the callback for debug purposes.

Refer to Callbacks Execution Flow in Callback Configuration Considerations to learn about how the SysPm processes the callbacks.

Callback Configuration Considerations

Callback Function Parameters

The callbackParams parameter of the callback function is a cy_stc_syspm_callback_params_t structure. The second parameter (mode) is for internal use. In the example code we used a dummy value CY_SYSPM_CHECK_READY to eliminate compilation errors associated with the enumeration. The driver sets the mode field to the correct value when calling the callback functions (the mode is referred to as step in the Callback Function Implementation). The callback function reads the value and executes code based on the mode set by the SysPm driver. The base and context fields are optional and can be NULL. Some drivers require a base hardware address and context to store information about the mode transition. If your callback routine requires access to the driver registers or context, provide those values (see PDL Design section to learn about Base Hardware Address). Be aware of MISRA warnings if these parameters are NULL.

Callback Function Structure

For each callback, provide a cy_stc_syspm_callback_t structure. Some fields in this structure are maintained by the driver. Use NULL for cy_stc_syspm_callback_t.prevItm and cy_stc_syspm_callback_t.nextItm. Driver uses these fields to build a linked list of callback functions. The value of cy_stc_syspm_callback_t.order element is used to define the order how the callbacks are put into linked list, and sequentially, how the callbacks are executed. See Callback Registering section.

warning

The Cy_SysPm_RegisterCallback() function stores a pointer to the cy_stc_syspm_callback_t structure. Do not modify elements of the cy_stc_syspm_callback_t structure after the callback is registered. You are responsible for ensuring that the structure remains in scope. Typically the structure is declared as a global or static variable, or as a local variable in the main() function.

Callback Function Implementation

Every callback function should handle four possible steps (referred to as “mode”) defined in cy_en_syspm_callback_mode_t :

  • CY_SYSPM_CHECK_READY - Check if ready to enter a power mode.

  • CY_SYSPM_BEFORE_TRANSITION - The actions to be done before entering the low power mode.

  • CY_SYSPM_AFTER_TRANSITION - The actions to be done after exiting the low power mode.

  • CY_SYSPM_CHECK_FAIL - Roll back any actions performed in the callback executed previously with CY_SYSPM_CHECK_READY.

A callback function can skip steps (see Defines to skip the callbacks modes). In our example myDeepSleep1 and myDeepSleep2 callbacks do nothing while entering the low power mode (skip on CY_SYSPM_BEFORE_TRANSITION). If there is anything preventing low power mode entry - return CY_SYSPM_FAIL in response to CY_SYSPM_CHECK_READY in your callback implementation. Note that the callback should return CY_SYSPM_FAIL only in response to CY_SYSPM_CHECK_READY. The callback function should always return CY_SYSPM_PASS for other modes: CY_SYSPM_CHECK_FAIL, CY_SYSPM_BEFORE_TRANSITION, and CY_SYSPM_AFTER_TRANSITION (see Callbacks Execution Flow).

Callbacks Execution Flow

This section explains what happens during a power transition, when callbacks are implemented and set up correctly. The following discussion assumes:

  • All required callback functions are defined and implemented

  • All cy_stc_syspm_callback_t structures are filled with required values

  • All callbacks are successfully registered

User calls one of the power mode transition functions: Cy_SysPm_CpuEnterSleep(), Cy_SysPm_CpuEnterDeepSleep(), Cy_SysPm_SystemEnterUlp(), Cy_SysPm_SystemEnterLp(), or Cy_SysPm_SystemEnterHibernate(). It calls each callback with the mode set to CY_SYSPM_CHECK_READY. This triggers execution of the code for that mode inside of each user callback.

The intent of CY_SYSPM_CHECK_READY is to only signal if the resources is ready to transition. Ideally, no transition changes should be made at this time. In some cases a small change may be required. For example a communication resource callback may set a flag telling firmware not to start any new transition.

If that process is successful for all callbacks, then Cy_SysPm_ExecuteCallback() calls each callback with the mode set to CY_SYSPM_BEFORE_TRANSITION. This triggers execution of the code for that mode inside each user callback. We then enter the low power mode after all callback are executed.

When exiting the low power mode, the SysPm driver executes Cy_SysPm_ExecuteCallback() again. This time it calls each callback in reverse order, with the mode set to CY_SYSPM_AFTER_TRANSITION. This triggers execution of the code for that mode inside each user callback. The final execution of callbacks depends on the low power mode in which callbacks were called:

  • For CPU Sleep or Deep Sleep power modes, the CY_SYSPM_AFTER_TRANSITION mode is called after the CPU wakes from Sleep or Deep Sleep.

  • For system Hibernate, the CY_SYSPM_AFTER_TRANSITION mode is not executed because the device reboots after the wakeup from the Hibernate.

  • For system LP and ULP modes, after the CY_SYSPM_AFTER_TRANSITION mode was called the system remains in the new power mode: LP or ULP.

A callback can return CY_SYSPM_FAIL only while executing the CY_SYSPM_CHECK_READY mode. If that happens, then the remaining callbacks are not executed. Any callbacks that have already executed are called again, in reverse order, with CY_SYSPM_CHECK_FAIL. This allows the system to return to the previous state. If a callback returns a fail then any of the functions (Cy_SysPm_CpuEnterSleep(), Cy_SysPm_CpuEnterDeepSleep(), Cy_SysPm_SystemEnterUlp(), Cy_SysPm_SystemEnterLp(), or Cy_SysPm_SystemEnterHibernate()) that attempt to switch the device into a low power mode will also return CY_SYSPM_FAIL.

Callbacks that reconfigure global resources, such as clock frequencies, should be registered last. They then modify global resources as the final step before entering the low power mode, and restore those resources first, as the system returns from low power mode.

Callback Registering

While registration the callback is put into the linked list. The place where the callback structure is put into the linked list is based on cy_stc_syspm_callback_t.order. The callback with the lowest cy_stc_syspm_callback_t.order value will be placed at the beginning of linked list. The callback with the highest cy_stc_syspm_callback_t.order value will be placed at the end of the linked list. If there is already a callback structure in the linked list with the same cy_stc_syspm_callback_t.order value as you attend to register, then your callback will be placed right after such a callback.

Such a registration order defines how the callbacks are executed:

    /* Register myDeepSleep1 */
    if (true != Cy_SysPm_RegisterCallback(&myDeepSleep1))
    {
        /* Insert error handling */
    }
    
    /* Register myDeepSleep2 */
    if (true != Cy_SysPm_RegisterCallback(&myDeepSleep2))
    {
        /* Insert error handling */
    }
    
    /* Register myDeepSleep3 */
    if (true != Cy_SysPm_RegisterCallback(&myDeepSleep3))
    {
        /* Insert error handling */
    }
Callbacks with equal cy_stc_syspm_callback_t.order values are registered in the same order as they are registered: ../../../_images/syspm_register_eq.png

Callbacks with a different cy_stc_syspm_callback_t.order value will be stored based on the cy_stc_syspm_callback_t.order value, with no matter when they when registered:

../../../_images/syspm_register_dif.png

This can be useful to ensure that system resources (clock dividers, etc) are changed right before entering low power mode and immediately after exiting from low power.

Callback Unregistering

Unregistering the callback might be useful when you need to dynamically manage the callbacks.

    /* Scenario: There is a need to unregister a previously registered callback */
    if (true != Cy_SysPm_UnregisterCallback(&myDeepSleep2))
    {
        /* Insert error handler */
    }
The callback structures after myDeepSleep2 callback is unregistered: ../../../_images/syspm_unregistration.png

Definitions

Term

Definition

LDO

Low dropout linear regulator. The functions that manage this block are grouped as LDO under Core Voltage Regulation

SIMO Buck

Single inductor multiple Output Buck regulator, referred as "Buck regulator" throughout the documentation. The functions that manage this block are grouped as Buck under Core Voltage Regulation

SISO Buck

Single inductor single output Buck regulator, referred as "Buck regulator" throughout the documentation. The functions that manage this block are grouped as Buck under Core Voltage Regulation

PMIC

Power management integrated circuit. The functions that manage this block are grouped as PMIC

LP

System low power mode. See the Switching the System into Low Power section for details.

ULP

System ultra low power mode. See the Switching the System into Ultra Low Power section for details.

More Information

For more information on the SysPm driver, refer to the technical reference manual (TRM).

Changelog

Version

Changes

Reason for Change

5.50

Added following functions for SRAM power mode configuration: Cy_SysPm_SetSRAMMacroPwrMode(), Cy_SysPm_SetSRAMPwrMode(), Cy_SysPm_GetSRAMMacroPwrMode(). For PSoC 64 devices these functions can return PRA driver status value.

Added support for SRAM power mode configuration.

5.40

Support for CM33.

New devices support.

5.30

Updated Cy_SysPm_LdoSetVoltage() and Cy_SysPm_SystemSetMinRegulatorCurrent() to extend the wakeup delay from Deep Sleep for 1.1 V LDO for the case when system regulator is configured to the minimum current mode. Please refer to System Regulator Current Mode for the more details on system regulator modes.

Ensure valid VCCD upon wakeup for the system regulator's minimum current mode.

Fixed MISRA 2012 violations.

MISRA 2012 compliance.

Updated the Cy_SysPm_CpuEnterDeepSleep() function to ensure the Low-power mode entry abort when a system call intiated by Cortex-M4 or Cortex-M0+ is pending.

Fixed the issue when the non-blocking flash write intitated by the Cortex-M4 application fails to complete because the Cortex-M0+ CPU is in Deep Sleep mode.

5.20

Updated Cy_SysPm_CpuEnterDeepSleep() function for the CYB06xx7 devices.

Added CYB06xx7 device support.

5.10

Updated the following functions for the PSoC 64 devices: Cy_SysPm_CpuEnterDeepSleep(), Cy_SysPm_SystemEnterLp(), Cy_SysPm_SystemEnterUlp, Cy_SysPm_SystemEnterHibernate, Cy_SysPm_SetHibernateWakeupSource, Cy_SysPm_ClearHibernateWakeupSource, Cy_SysPm_SystemSetMinRegulatorCurrent, Cy_SysPm_SystemSetNormalRegulatorCurrent, Cy_SysPm_LdoSetVoltage, Cy_SysPm_LdoSetMode, Cy_SysPm_BuckEnable, Cy_SysPm_BuckSetVoltage1, Following functions are updated as unavailble for PSoC 64 devices: Cy_SysPm_WriteVoltageBitForFlash, Cy_SysPm_SaveRegisters, Cy_SysPm_RestoreRegisters, Cy_SysPm_BuckSetVoltage2, Cy_SysPm_BuckEnableVoltage2, Cy_SysPm_BuckDisableVoltage2, Cy_SysPm_BuckSetVoltage2HwControl, SetReadMarginTrimUlp, SetReadMarginTrimLp, SetWriteAssistTrimUlp, IsVoltageChangePossible.

Added PSoC 64 device support.

For PSoC 64 devices the following functions can return PRA driver status value: Cy_SysPm_CpuEnterDeepSleep(), Cy_SysPm_SystemEnterHibernate(), Cy_SysPm_SystemEnterLp(), Cy_SysPm_SystemEnterUlp(), Cy_SysPm_SystemSetMinRegulatorCurrent(), Cy_SysPm_SystemSetNormalRegulatorCurrent(), Cy_SysPm_LdoSetVoltage(), Cy_SysPm_LdoSetMode(), Cy_SysPm_BuckEnable(), Cy_SysPm_BuckSetVoltage1(),

For PSoC 64 devices the SysPm driver uses the PRA driver to change the protected registers. A SysPm driver function that calls a PRA driver function will return the PRA error status code if the called PRA function returns an error. In these cases, refer to PRA return statuses cy_en_pra_status_t.

Minor documentation updates.

Documentation enhancement.

5.0

Updated the internal IsVoltageChangePossible() function (Cy_SysPm_LdoSetVoltage(), Cy_SysPm_BuckEnable(), Cy_SysPm_BuckSetVoltage1(), Cy_SysPm_SystemEnterUlp() and Cy_SysPm_SystemEnterLp() functions are affected). For all the devices except CY8C6xx6 and CY8C6xx7 added the check if modifying the RAM trim register is allowed.

Protecting the system from a possible CPU hard-fault cause. If you are using PC > 0 in your project and you want to switch the power modes (LP<->ULP), you need to unprotect the CPUSS_TRIM_RAM_CTL and CPUSS_TRIM_ROM_CTL registers and can use a programmable PPU for that.

4.50

Updated the Cy_SysPm_CpuEnterDeepSleep() function.

Updated the mechanism for saving/restoring not retained UDB and clock registers in the Cy_SysPm_CpuEnterDeepSleep() function.

Updated the Cy_SysPm_CpuEnterDeepSleep() function to use values stored into the variable instead of reading them directly from SFLASH memory.

SFLASH memory can be unavailable to read the correct value after a Deep sleep state on the CY8C6xx6 and CY8C6xx7 devices.

4.40

Fixed Cy_SysPm_LdoSetVoltage(), Cy_SysPm_BuckEnable(), and Cy_SysPm_BuckSetVoltage1() functions. Corrected the sequence for setting the RAM trim value. This behavior is applicable for all devices, except CY8C6xx6 and CY8C6xx7.

For all devices, except CY8C6xx6 and CY8C6xx7, the trim sequence was setting incorrect trim values for RAM. This could cause a CPU hard fault.

4.30

Corrected the Cy_SysPm_CpuEnterDeepSleep() function. Removed early access to flash values after system Deep Sleep, when flash is not ready to be used. Now the Cy_SysPm_CpuEnterDeepSleep() function does not access flash until the flash is ready. This behavior is applicable only on multi-CPU devices CY8C6xx6 and CY8C6xx7.

For CY8C6xx6 and CY8C6xx7 early access to flash values after system Deep Sleep could potentially cause hard fault. Now after system Deep Sleep only ram values are used before flash is ready.

4.20

Updated the Cy_SysPm_RegisterCallback() function. Added a new element to callback structure - cy_stc_syspm_callback_t.order

Enhanced the mechanism of callbacks registration and execution. Now callbacks can be ordered during registration. This means the execution flow now is based on cy_stc_syspm_callback_t.order. For more details, see the Callback Registering section.

Updated SysPm Callbacks section. Added Callback Registering section

Added explanations how to use updated callbacks registration mechanism.

Added new function Cy_SysPm_GetFailedCallback()

Added new functionality to support callback debugging

4.10.1

Updated the Cy_SysPm_BackupEnableVoltageMeasurement() description

Changed the scale number from 40% to 10% to correctly reflect a real value.

4.10

Updated the Cy_SysPm_CpuEnterDeepSleep() function.

Corrected the mechanism for saving/restoring not retained UDB registers in the Cy_SysPm_CpuEnterDeepSleep() function.

Now, the Cy_SysPm_CpuEnterDeepSleep() function does not put CM0+ CPU into Deep Sleep and returns CY_SYSPM_SYSCALL_PENDING status, if a syscall operation is pending. This behavior is applicable on multi-CPU devices except CY8C6xx6 and CY8C6xx7.

Updated the Cy_SysPm_CpuEnterSleep() function.

Removed the redundant second call of the WFE() instruction on CM4 CPU. This change is applicable for all devices except CY8C6xx6, CY8C6xx7.

Added a new CY_SYSPM_SYSCALL_PENDING return status.

Expanded driver return statuses for indicating new possible events in the driver.

4.0

Flattened the organization of the driver source code into the single source directory and the single include directory.

Driver library directory-structure simplification.

Changed power modes names. See System Power Modes.

Renamed the following functions:

  • Cy_SysPm_Sleep to Cy_SysPm_CpuEnterSleep

  • Cy_SysPm_DeepSleep to Cy_SysPm_CpuEnterDeepSleep

  • Cy_SysPm_Hibernate to Cy_SysPm_SystemEnterHibernate

  • Cy_SysPm_SleepOnExit to Cy_SysPm_CpuSleepOnExit

  • Cy_SysPm_EnterLowPowerMode to Cy_SysPm_SystemSetMinRegulatorCurrent

  • Cy_SysPm_ExitLowPowerMode to Cy_SysPm_SystemSetNormalRegulatorCurrent

  • Cy_SysPm_IsLowPower to Cy_SysPm_IsSystemUlp

For all renamed functions, added BWC macros to simplify migration.

Device power modes simplification

Added the following functions:

  • Cy_SysPm_LdoSetMode

  • Cy_SysPm_LdoGetMode

  • Cy_SysPm_WriteVoltageBitForFlash

  • Cy_SysPm_SaveRegisters

  • Cy_SysPm_RestoreRegisters

  • Cy_SysPm_CpuSendWakeupEvent

  • Cy_SysPm_SystemIsMinRegulatorCurrentSet

  • Cy_SysPm_SystemEnterLp

  • Cy_SysPm_SystemEnterUlp

  • Cy_SysPm_IsSystemLp

Added new functionality to configure device power modes

Callback mechanism changes:

  • Removed the limitation for numbers of registered callbacks. Previously it was possible to register up to 32 callbacks. Now the maximum registered callbacks is not limited by the SysPm driver.

  • Internal enhancement in callback execution flow.

  • Changes with BWC issues:

    1. Removed the mode element from cy_stc_syspm_callback_params_t structure. Now this element is a separate parameter in the callback function.

    2. Changed the interface of the callback function, added the cy_en_syspm_callback_mode_t mode parameter:

Callback mechanism enhancements

Added register access layer. Use register access macros instead of direct register access using dereferenced pointers.

Makes register access device-independent, so that the PDL does not need to be recompiled for each supported part number.

Added Migration Guide: Moving to SysPm v4.0.

Provided a guidance for migrating to the latest SysPm driver version

3.0

Removed three functions:

  • Cy_SysPm_Cm4IsLowPower

  • Cy_SysPm_Cm0IsLowPower

  • Cy_SysPm_IoFreeze

Removed the following macros:

  • CY_SYSPM_STATUS_CM0_LOWPOWER

  • CY_SYSPM_STATUS_CM4_LOWPOWER

Removed the two functions Cy_SysPm_Cm4IsLowPower, Cy_SysPm_Cm0IsLowPower because low power mode is related to the device and not to the CPU. The function Cy_SysPm_IsSystemUlp must be used instead of these two functions.

Removed Cy_SysPm_IoFreeze because the are no known use cases with IOs freeze in power modes, except Hibernate. In Hibernate power mode, the IOs are frozen automatically.

Corrected the syspm callback mechanism behavior. Now callbacks with CY_SYSPM_AFTER_TRANSITION mode are executed from the last registered to the first registered. Previously callbacks with CY_SYSPM_AFTER_TRANSITION mode were executed from last executed to the first registered.

Corrected the syspm callbacks execution sequence

2.21

Removed saving/restoring the SysClk measurement counters while in Deep Sleep routine

Removed possible corruption of SysClk measurement counters if the core wakes up from the Deep Sleep.

2.20


  • Added support for changing core voltage when the protection context is other that zero. Such support is available only for devices that support modifying registers via syscall.

  • For preproduction PSoC 6 devices the changing core voltage is prohibited when the protection context is other than zero.

  • Updated the following functions. They now have a cy_en_syspm_status_t return value and use a syscall:

    • Cy_SysPm_LdoSetVoltage

    • Cy_SysPm_BuckSetVoltage1

    • Cy_SysPm_BuckEnable

    No backward compatibility issues.

  • Added new CY_SYSPM_CANCELED element in the cy_en_syspm_status_t.

  • Documentation updates.

  • Added warning that Cy_SysPm_PmicDisable(CY_SYSPM_PMIC_POLARITY_LOW) is not supported by hardware.

Added support for changing the core voltage in protection context higher than zero (PC > 0).

Documentation update and clarification

2.10


  • Changed names for all Backup, Buck-related functions, defines, and enums

  • Changed next power mode function names: Cy_SysPm_EnterLowPowerMode Cy_SysPm_ExitLpMode Cy_SysPm_SetHibWakeupSource Cy_SysPm_ClearHibWakeupSource Cy_SysPm_GetIoFreezeStatus

  • Changed following enumeration names: cy_en_syspm_hib_wakeup_source_t cy_en_syspm_simo_buck_voltage1_t cy_en_syspm_simo_buck_voltage2_t

  • Updated Power Modes documentation section

  • Added Low Power Callback Managements section

  • Documentation edits


  • Improvements made based on usability feedback

  • Documentation update and clarification

2.0

Enhancement and defect fixes:

  • Added input parameter(s) validation to all public functions

  • Removed "_SysPm_" prefixes from the internal functions names

  • Changed the type of elements with limited set of values, from uint32_t to enumeration

  • Enhanced syspm callback mechanism

  • Added functions to control:

    • Power supply for the Vddbackup

    • Supercapacitor charge

    • Vddbackup measurement by ADC

1.0

Initial version

Migration Guide: Moving to SysPm v4.0

This section provides a guideline to migrate from v2.21 to v4.0 of the SysPm driver.

Introduction

If your application currently uses SysPm v2.21 APIs, you must migrate to SysPm v4.0 so that your application continues to operate.

Take a few minutes to review the following information:

  • The APIs related to PSoC 6 Power Modes are changed. Old power modes APIs function names are now deprecated and should not be used in new applications.

  • The SysPm Callbacks mechanism is changed. The mode element is removed from cy_stc_syspm_callback_params_t structure. Now this element is a separate parameter in the callback function.

Migrating to new power modes APIs.

The table below shows the new APIs names that should be used in the application instead of old names:

SysPm v2.21 API name

SysPm v4.0 API name

Comment

Cy_SysPm_Sleep

Cy_SysPm_CpuEnterSleep

Renamed, no functional changes

Cy_SysPm_DeepSleep

Cy_SysPm_CpuEnterDeepSleep

Renamed, no functional changes

Cy_SysPm_Hibernate

Cy_SysPm_SystemEnterHibernate

Renamed, no functional changes

Cy_SysPm_SleepOnExit

Cy_SysPm_CpuSleepOnExit

Renamed, no functional changes

Cy_SysPm_IsLowPower

Cy_SysPm_IsSystemUlp

Now this function checks whether the device is in ULP mode

Cy_SysPm_EnterLowPowerMode

Cy_SysPm_SystemSetMinRegulatorCurrent

The low power active mode does not exist anymore. The System Regulator Current Mode is implemented instead

Cy_SysPm_ExitLowPowerMode

Cy_SysPm_SystemSetNormalRegulatorCurrent

The low power active mode does not exist anymore. The System Regulator Current Mode is implemented instead

Cy_SysPm_Cm4IsLowPower

Removed

This function is removed because low power mode is related to the system and not to the CPU

Cy_SysPm_Cm0IsLowPower

Removed

This function is removed because low power mode is related to the system and not to the CPU

Cy_SysPm_IoFreeze

Removed

This function is removed because there are no known use cases to freeze in power modes other than Hibernate

In addition to renamed power modes APIs, the following defines and enum elements names are changed:

SysPm v2.21 defines

SysPm v4.0 defines

Comment

CY_SYSPM_ENTER_LP_MODE

CY_SYSPM_ULP

The cy_en_syspm_callback_type_t element is renamed to align callback types names to new power modes names

CY_SYSPM_EXIT_LP_MODE

CY_SYSPM_LP

The cy_en_syspm_callback_type_t element is renamed to align callback types names to new power modes names

CY_SYSPM_STATUS_SYSTEM_LOWPOWER

CY_SYSPM_STATUS_SYSTEM_ULP

Status define, renamed to align new power modes names and abbreviations

Migrating to SysPm v4.0 callbacks

Review this section if your application is using the syspm callback mechanism.

To migrate to SysPm v4.0 callbacks you need to perform the following steps:

  1. Remove mode element from all cy_stc_syspm_callback_params_t structures defined in your application. In SysPm v2.21 this structure is:

    cy_stc_syspm_callback_params_t deepSleepParam1 =
    {
        CY_SYSPM_CHECK_READY,
        &HW1_address,
        &context
    };
    

    In SysPm v4.0 this structure should be:

    cy_stc_syspm_callback_params_t deepSleepParam1 =
    {
        &HW1_address,
        &context
    };
    

  2. Update all defined syspm callback function prototypes to have two parameters instead of one. The SysPm v2.21 callback function prototype is:

    cy_en_syspm_status_t Func1 (cy_stc_syspm_callback_params_t *callbackParams);
    
    The SysPm v4.0 callback function prototype should be:
    cy_en_syspm_status_t Func1 (cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode);
    

  3. Change the syspm callback function implementation to not use a mode value as an element of the callbackParams structure, but, as separate function parameter: SysPm v2.21 callback function implementation:

    cy_en_syspm_status_t Func1(cy_stc_syspm_callback_params_t *callbackParams)
    {
        cy_en_syspm_status_t retVal = CY_SYSPM_FAIL;
    
        switch(callbackParams->mode)
        {
            case CY_SYSPM_CHECK_READY:
            ...
        }
    
        return (retVal);
    }
    
    SysPm v4.0 callback function implementation:
    cy_en_syspm_status_t Func1(cy_stc_syspm_callback_params_t *callbackParams, cy_en_syspm_callback_mode_t mode)
    {
        cy_en_syspm_status_t retVal = CY_SYSPM_FAIL;
    
        switch(mode)
        {
            case CY_SYSPM_CHECK_READY:
            ...
        }
    
        return (retVal);
    }
    
    After the changes above are done, you have successfully migrated to SysPm v4.0.

Do not forget to review newly added functionality for SysPm v4.0 in the Changelog.