tests: Add pm.wakeup_external_interrupt test.

[gbarkadiusz]

Proposal: A new test verifies that the system can wake up from sleep modes using an external interrupt, based on a new approach outlined in #80989.

pm.wakeup_external_interrupt
The test consists of two components:

• Controller: Sends an external interrupt.
• Target Board: Enters a sleep state and waits for the external interrupt from the controller.

The external interrupt is implemented using a simple GPIO pin to signal between the two components. For more details read the README.md file.

This pr is marked as DNM because of Debug commit and going discussion in RFC. #80989.

[bjarki-andreasen]

When it comes to wakeups, I would expect us to simply monitor for the boot banner? seems a bit more stable than looking solely at increases in current consumption, that could be due to many things :)

[gbarkadiusz]

When it comes to wakeups, I would expect us to simply monitor for the boot banner? seems a bit more stable than looking solely at increases in current consumption, that could be due to many things :)

I see. Let me read more about the boot banner. I need to dive into this topic.
P.S. If the boot banner consistently appears after every wakeup, we might not need an additional Power Monitor to verify the wakeup functionality triggered by an external interrupt.

However, relying only on the boot banner does not confirm whether the system successfully entered the intended low-power state before waking up. For a complete validation, monitoring power consumption or another indicator of the low-power state is still necessary.

[bjarki-andreasen]

When it comes to wakeups, I would expect us to simply monitor for the boot banner? seems a bit more stable than looking solely at increases in current consumption, that could be due to many things :)

I see. Let me read more about the boot banner. I need to dive into this topic. P.S. If the boot banner consistently appears after every wakeup, we might not need an additional Power Monitor to verify the wakeup functionality triggered by an external interrupt.

What is triggering the external interrupt BTW? I find it hard to find in the commits :)

However, relying only on the boot banner does not confirm whether the system successfully entered the intended low-power state before waking up. For a complete validation, monitoring power consumption or another indicator of the low-power state is still necessary.

Since the test suite is run on the target, we would need to allow the test suite to be restarted by twister, without triggering RESET pin, we would essentially have a current measurement test suite, which ends with poweroff(), and having twister trigger wakeup by pin.

Starts to get complicated fast :D

[gbarkadiusz]

When it comes to wakeups, I would expect us to simply monitor for the boot banner? seems a bit more stable than looking solely at increases in current consumption, that could be due to many things :)

I see. Let me read more about the boot banner. I need to dive into this topic. P.S. If the boot banner consistently appears after every wakeup, we might not need an additional Power Monitor to verify the wakeup functionality triggered by an external interrupt.

What is triggering the external interrupt BTW? I find it hard to find in the commits :)

However, relying only on the boot banner does not confirm whether the system successfully entered the intended low-power state before waking up. For a complete validation, monitoring power consumption or another indicator of the low-power state is still necessary.

Since the test suite is run on the target, we would need to allow the test suite to be restarted by twister, without triggering RESET pin, we would essentially have a current measurement test suite, which ends with poweroff(), and having twister trigger wakeup by pin.

Starts to get complicated fast :D

The wake up is triggering by pytest under twister. The test_wakeup_external_interrupt.py test connects to the controller shell and controls the corresponding pin PD6.
https://github.com/zephyrproject-rtos/zephyr/pull/81522/files#diff-677e2d8216d388c6e71c128e10ce14d42233fdfde84fc5b2b6e293517ce67083R19
So, the twister has completely control under target.

PS: I tried to automatize the waking up the board by external interrupt.