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.
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.
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.
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.
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?