5 Replies Latest reply on Nov 27, 2020 1:54 AM by MaMi_1205306

    PSoC5LP : Wake up from hibernate mode by PICU


      Dear Sirs and Madams,


      We would like to confirm about wake up by PICU from the hibernate mode.


      The following code on line 1231 of cyPM.c,

      I understand that wakeup will start this process.


          CY_PM_WFI;  // line 12331


      What are the conditions for moving to this process?


      (a) Pin component irq goes to High

      (b) ISR is enabled (Derived)

      (c) Both (a) and (b)


      I have confirmed that the condition is (c),

      In other words, is it correct to understand that PICU is not only the pin component irq but also ISR by iqr?


      I decided the reason by the following test using CY8CKIT-059.


      The following configuration of the attached project works fine.



      Even if you change it as shown below, it will return to normal.


      However, if the ISR component is excluded as shown below and the ISR process in main.c is commented out, it will not wake up.



        • 1. Re: PSoC5LP : Wake up from hibernate mode by PICU



          I tested your project.   I can reproduce your results.


          The best I can figure is that assigning the irq SW is not enough.   You need the isr connection to all the Application Build phase to route the SW interrupt to the wakeup_out of the PICU.   Otherwise the code doesn't come back from the CY_PM_WFI of the hibernate action.


          There is this section of the Pin component datasheet.

          Having an irq component is small price to pay for a much needed feature such as Hibernate mode.



          • 2. Re: PSoC5LP : Wake up from hibernate mode by PICU



            I thought it wouldn't wake up if the irq of Pin component and ISR component weren't connected.

            I didn't expect to use irq unconnected in the first place.


            However, I heard and confirmed that even if it is used in that way, it will transition from hibernate to active.

            In other words, I understand that PICU must be High for both irq and ISR,


            As you told me, it may not work at the rising edge,

            Note that even if you intentionally remove the ISR component to disable interrupts, irq will be accepted if the ISR is set to High by other interrupt processing.


            Thank you,

            • 3. Re: PSoC5LP : Wake up from hibernate mode by PICU

              Hi MaMi-san,


              Your observation is right, both the wake-up source and an interrupt are required to completely wake-up the device from hibernate (or sleep mode of the PSoC5LP device)

              But it does not seem to matter whether the interrupt component is connected to the wake-up source or is unrelated to it (as the interrupt connected to logic 1 in your example wakes up the device)


              I tried to make some tests to understand what is the role of the unrelated interrupt in waking up the device. Based on this, it appears that:

              - The wake-up source(such as PICU) alone is sufficient to partly wake-up the device apart from the ARM CPU, in the sense that the IMO starts running when the wake-up source is triggered.

              - But after this, some interrupt is needed to get the ARM CPU out of the WFI(wait for interrupt) instruction and complete the wake-up process. This interrupt need not necessarily be connected to the wake-up source.


              Attached is a modification of your project where an IMO divided clock is observed on an LED on CY8CKIT-059.

              It can be seen that with just the PICU wakeup source, when SW1 is pressed, the LED starts blinking at a fast rate indicating that the IMO based clock is active.

              But only when an interrupt also is enabled (you can enable Page2 in the project schematic and uncomment isr_1_StartEx) then the CPU also starts running and you can observe the slower firmware LED toggles mixed with the faster clock toggles.


              PSoC5LP hibernate wakeup behavior test project screenshot.jpg



              1) The T-flip flop chain in the project is only to slow down the IMO frequency further to a rate observable on LED. Otherwise, the clock can be directly connected to a pin and observed on scope.

              2) The OR gate is used to observe both the low speed firmware toggles and the faster clock toggles on the single LED available on CY8CKIT-059. Again this is not required, when observing the clock on a scope.

              3) The Clock_1 (IMO divided clock) is enabled after CyPmSaveClocks in the code. This is only to check hibernate wake-up behavior because the CyPmSaveClocks() disables all clocks. It is not intended for later application use, and can later be removed.


              The above tests are only the understand the behavior of the device.

              The typical usage is to have the interrupt connected to the wake-up source itself and it may not make much sense to have a different interrupt source. Also, there are not many interrupt options to be able to actively generate an interrupt in low power modes, because the component connected to the interrupt component may not run in the low power mode.


              Best Regards,

              Prem Sai

              • 4. Re: PSoC5LP : Wake up from hibernate mode by PICU

                I confirmed the attached project.


                However, I don't understand why the pin component irq is unconnected and why it wakes up from hibernate mode.


                It is necessary to know the details of the conditions under which the "wakeup_out" signal described below of the PSoC5LP architecture TRM is satisfied.

                In other words, is this "wakeup_out" established by the OR circuit only with the pin component irq?

                Is there any material that shows what kind of circuit this "wakeup_out" signal is connected to and used?



                • 5. Re: PSoC5LP : Wake up from hibernate mode by PICU

                  I experimented and understood it in the thread below.


                  PSoC5LP : Confirmation of wakeup_out signal


                  I apologize for the resulting multithreading.