tests: pm: Adding tests based on new approach to PM testing.

[gbarkadiusz]

• Introduces two scripts abstract_power_monitor.py and pwsh_stm32l562.py.

• Adds three new power management pytests based on a new approach.

SETUP

TESTS

pm.states: Verifies the transition to all available power states on stm32l562e_dk.

During the test, pytest detects each step and calculates the RMS (Root Mean Square) current for every detected state. The test then compares the calculated RMS values against the expected values, which have been determined manually through experimental observation

pm.residency_time: Tests the residency time of each power state.
This test evaluates the residency time of different power states on the stm32l562e_dk board.

pm.wakeup_timer: Tests the RTC alarm’s ability to wake the CPU from the lowest power state.

Each test calculates RMS current values for each detected state and compares them to expected values, which were manually set based on experimental data.

To Reproduce

1. Configure the stm32l562e_dk board according to the instructions provided above.
2. Connect both USB ports of the board to your host system. The board will appear as two separate targets:
   Power Monitor: e.g., /dev/ttyACM0 or /dev/serial/by-id/usb-STMicroelectronics_PowerShield__Virtual_ComPort_in_FS_Mode__FFFFFFFEFFFF-if00
   Target: e.g., /dev/ttyACM1 or /dev/serial/by-id/usb-STMicroelectronics_STLINK-V3_004##############39-if02
3. Copy the path of the Power Monitor and update the <path_to_power_monitor> in the tests/subsys/pm/power_states/testcase.yaml file under the pytest_args section as follows:
   pytest_args: [--powershield=<path_to_power_monitor>]
4. Run the following command to execute the test:
   twister --device-testing --device-serial <path_to_target> -p stm32l562e_dk -s <test_name> -x=CONFIG_BOOT_DELAY=500

[hakehuang]

can we move those expected data to a yaml file for different platform?

[gbarkadiusz]

Of course we can, the good hint. Thank you.

[gbarkadiusz]

PS: Btw, Please take a look. #80989. Feel free to share ideas or warries. :)

[hakehuang]

can we use this tests\subsys\pm\power_mgmt_soc\src\power_mgmt.c, instead of the sleep time?

[gbarkadiusz]

I don't know yet, let me see.

[ceolin]

Yep, get the information from the device tree is the way to go imho, otherwise it will not be portable and the previous comment is useless.

[gbarkadiusz]

@ceolin I added the use of DTS, is this what you meant?

[hakehuang]

would this be better to move this function to scripts/pm/pm_helper.py, and rms is not the only implement, e.g. we can have average mean

[gbarkadiusz]

@hakehuang I've moved the hardcoded expected value to the appropriate yaml file. Please take a look.

[hakehuang]

looks good

[erwango]

IIUC these need to be set manually before testing, right ?

Any way we can spare the need for manual update ?
At least, <path_to>/stm32l562e_dk.yaml is rather static, so it looks reachable.
For <path_to>/STMicroelectronics_PowerShield__Virtual_ComPort maybe a dedicated twister configuration could be used or added ?

[bjarki-andreasen]

I believe the approach in this PR is too highly coupled to pm power states, a specific power monitor, and a specific test case.

Measuring current/power or anything else is "generic", its measured in SI units, and can be performed by an "endless" variation of probes. I compare measuring power with "any probe" to flashing a board with "any runner", be it jlink, openocd, pyocd, or whatever.

I believe it can and should be as simple to define a testcase requiring power measurements as this
testcase.yaml:

tests:
  pm.power_states:
    harness: probe
    harness_config:
      measurements:
        - name: k_cpu_idle:
          rms: 56.0
        - name: state_0:
          rms: 56.0

The measurements could be anything, a mode, some peripheral being on, like a comparator in low power mode:

        - name: comp_low_power:
          rms: 56.0
        - name: comp_high_power:
          rms: 71.0

and that specific probes, like runners, should be defined like --probe stm_powershield and --probe-port /dev/ttyACM0 if required, to specify which probe to use for the test. See https://docs.zephyrproject.org/latest/develop/test/twister.html#running-tests-on-hardware for example. Any testsuite can be run for any board, with whatever flasher is available and supported.

This is important, as the test case should not depend on any specific probe, if one developer has a JouleScope, another has a Nordic PPK2, and a third has an stm_powershield, they should all be able to run the same testcase. We are measuring the same "generic" properties after all.

This PR keeps a bunch of this local, using pytest, but I don't think that is a nice, scalable approach to power measurements.