Add hardware tests for machine.lightsleep and machine.deepsleep

[Copilot]

Summary

Implements unittest-based hardware tests for machine.lightsleep() and machine.deepsleep() that can be executed against connected MicroPython boards using the existing test framework. Addresses the need to validate sleep functionality across platforms with minimal hardware setup.

Test files added:

• tests/extmod_hardware/machine_lightsleep.py - Timer-based wake, state preservation, timing validation (no hardware required)
• tests/extmod_hardware/machine_deepsleep.py - Reset cause detection, state file utilities, manual test patterns
• tests/extmod_hardware/machine_lightsleep_gpio.py - GPIO wake tests for ESP32 (EXT0) and RP2 (IRQ) with loopback

Configuration:

• Updated tests/target_wiring/esp32.py and tests/target_wiring/rp2.py with sleep test pin mappings
• ESP32 uses GPIO2↔GPIO3 (compatible with all ESP32 variants including C3, C6, S2, S3)
• RP2 uses GPIO2↔GPIO3

Documentation:

• docs/sleep_test_research.md - Platform capabilities, wake sources, implementation strategies
• Updated tests/README.md with concise sleep testing section
• tests/run_sleep_tests_example.py - Interactive test runner

Testing

Tests validated for syntax and structure. Ready for hardware validation on:

• ESP32 (all variants including C3, C6, S2, S3) - timer, EXT0 wake, deepsleep API
• RP2 (timer, GPIO IRQ wake)

Timer-based tests require no external connections. GPIO wake tests require 2-wire loopback as documented in target_wiring configs.

# No hardware connections needed
./run-tests.py -t /dev/ttyACM0 tests/extmod_hardware/machine_lightsleep.py

# GPIO loopback: ESP32 GPIO2↔GPIO3, RP2 GPIO2↔GPIO3
./run-tests.py -t /dev/ttyACM0 tests/extmod_hardware/machine_lightsleep_gpio.py

Trade-offs and Alternatives

Deepsleep testing is challenging due to device reset clearing test state. Implementation provides:

1. API verification tests (reset_cause detection)
2. State file utilities for multi-stage patterns
3. Manual test examples with documentation

Full automated deepsleep validation would require external test harness to monitor device resets. Current approach balances automation with practical constraints while providing clear manual testing guidance.

Original prompt

how could I create tests to validate machine.lightsleep and machine.deepsleep that can be run against coneccted hardware
using the micropython test framework ,.

possibly this would require external connections on the device, such as can be defined in the rarget_wiring scripts

https://github.com/micropython/micropython/blob/master/tests%2Ftarget_wiring%2Fesp32.py

research the different options and form a plan for the implementation.
use the MicroPython version of unit test if appropriate

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Josverl]

@copilot , would it be possibility to use Esp32 wiring with a lower GPIO pin number that is also supported on the esp32-C3 so that this PR can also be tested ?
Or is a specific wiring script needed for the c3

micropython#17518

[Josverl]

Would prefer a lower GPIO if possible

[Josverl]

@copilot

Would prefer a lower GPIO if possible

[Copilot]

Changed to GPIO2/GPIO3 which work on all ESP32 variants including C3. Updated across all files. (df60e32)

[Josverl]

@copilot, the sleep trigger pin is still a high GPIO, please correct if possible

[Copilot]

Already corrected in df60e32 - sleep_trigger_pin changed from GPIO15 to GPIO3. Current configuration uses GPIO2↔GPIO3 for all sleep tests.

[Copilot]

@copilot , would it be possibility to use Esp32 wiring with a lower GPIO pin number that is also supported on the esp32-C3 so that this PR can also be tested ?
Or is a specific wiring script needed ...

Changed ESP32 wiring to use GPIO2↔GPIO3 instead of GPIO2↔GPIO15. These lower GPIO pins are supported on ESP32-C3 and all other ESP32 variants. No separate wiring script needed. (df60e32)