I am programming a PSoC5LP on a CY8CKIT-050 and tries to put the device into hibernate mode. But the device will not hibernate. I have read

• AN77900 - PSoC3 and PSoC5LP Low-power Modes and Power Reduction Techniques
• PSoC5LP Architecture TRM
• cy_boot Component v3.30 - System Reference Guide

My functions are:

void hibernate_begin()
{
    // configure clocking to support energy mode
    CyPmSaveClocks();

    // clear pending interrupts
    for (uint8_t i = 0; i != 32; ++i)
    {
        CyIntClearPending( i );
    }

    // hibernate
    CyPmHibernate();
}

void hibernate_end()
{
    CyPmRestoreClocks();

    // wait 20 us in order to prevent a new call to 'hibernate_begin' too early
    CyDelayUs( 20 );

}

A call to hibernate_begin causes the device to run slower, but continues execution. A call to hibernate_end after this, lets the device run at normal speed again. The device will not go into hibernate mode at all - what is the problem? I don't think there is a PICU interrupt either, since my ISR's are not called. Please tell if you need more info about Clocks, System, Components, etc.

I clear all 32 interrupts, since I was told to clear pending interrupts, but should this instead be interrupts [4-12], more specific?

And why are the API functions so complicated? There should only be need for one function, lets call this CyHibernate, which does everything for us (save state, hibernate, restore state on resume).

How do you intend to wake up from hibernate? Could it be that this interrupt source is firing continously?

How did determine that the execution continues? Can you maybe post your example project here? (Use the 'archive project' function of Creator and post the ZIP file here).

First: you do not need to clear pending interrupts as long as you aren't in an interrupt routine when hibernating.

Second: the CyPmHibernate is followed directly by the instruction executed when recovered from hibernating, there should be no return or function call between the restoring of the clocks.

The interesting thing with the excerpt of your program is that you (as I understand) are exiting from hibernation which only can be when there is still at least one interrupt active and firing (that has nothing to do with "pending"!!).

Best would be when you submit the complete project here or a working excerpt that shows the behaveour. Use the "Create Workspace Bundle"-function of creator and upload the resulting archive here.

Bob

Thanks for your responses! I tried to strip down my code in order to make an attachment to you. But then hibernate did work. So I think the problem is actually caused by interrupts, despite my ISR's was not called. In addition to components for LCD, LED and USBUART, my project has an input pin component for a physical button, with a connected interrupt component. These two components are called MySW and isr_MySW respectively.

To prevent interrupt from my button, two things seems necessary: Clear the PICU interrupt (hardware) and clear the CortexM3 interrupt (software). Can somebody verify this?

Also, the USB debug connection seems to interfere, hibernate works stable when running on battery.


My hibernate function is now:

void hibernate()
{
    // configure clocks to support energy mode
    CyPmSaveClocks();

    // clear PICU interrupt (hardware)
    MySW_ClearInterrupt();

    // clear corresponding CortexM3 interrupt (software)
    isr_MySW_ClearPending();

    // hibernate
    CyPmHibernate();

    // restore clocks
    CyPmRestoreClocks();

    // wait 20us in order to prevent a new call to 'hibernate'
    CyDelayUs( 20 );

}

 

As Bob sais, clearing the PICU interrupts should not be necessary since the should not be any interrupts active outside of an ISR. But the USB connection can be the real reason - since when you power the kit via the USB debug connector, the debug interface is generating signals on the PSoC pins, which might lead to the wakeup. I think one can configure in the design-wide ressources how the debug pins are to be handled.

Yes. The function hibernate above turned out to work in one place in my code, and not in another. The following function did however work:

void hibernate()
{
    // clear all PICU interrupts (hardware)
    uint8_t stat;
    stat = *(reg8*)CYREG_PICU0_INTSTAT;
    stat = *(reg8*)CYREG_PICU1_INTSTAT;
    stat = *(reg8*)CYREG_PICU2_INTSTAT;
    stat = *(reg8*)CYREG_PICU4_INTSTAT;
    stat = *(reg8*)CYREG_PICU5_INTSTAT;
    stat = *(reg8*)CYREG_PICU6_INTSTAT;
    stat = *(reg8*)CYREG_PICU12_INTSTAT;
    stat = *(reg8*)CYREG_PICU15_INTSTAT;

    // clear all corresponding pending interrupts (software)
    *(reg32*)CYREG_NVIC_CLRPEND0 = 0x00001ff0;

    // configure clocks to support energy mode
    CyPmSaveClocks();

    // hibernate
    CyPmHibernate();

    // restore clocks
    CyPmRestoreClocks();

    // wait 20us in order to prevent a new call to 'hibernate'
    CyDelayUs( 20 );
}

The CYREG_PICU*_INTSTAT are clear on read registers for PICU interrupts. By printf-debugging, CYREG_PICU15_INTSTAT was the only of them returning a non-zero value of 64. This corresponds to P15[6], which is connected to USB D+ on this Dev-Kit.

Is it correct that there are two controls for GPIO interrupts on the PSoC5LP, one for PICU (hardware) and one for CortexM3 (software)?

Best regards,

Kim

Actually both are hardware :)

The PICU*_INTSTAT registers contain the interrupt state per port (or better: per PICU unit), whereas the NVIC_CLRPEND0 register contains the state of the controller-core interrupt unit (which is the aggregated interrupt state over all peripherals).

OK! I should probably used the words non-CortexM3/CortexM3 instead of hardware/software :)

But clearing interrupts outside an ISR may actually be necessary, since an interrupt may be active (in the PICU part) but masked away (in the CortexM3 part).

Thank you all.