RP2350 the watchdog timer does not count down while lightsleep is running
Port, board and/or hardware
Raspberry Pi Pico2
MicroPython version
MicroPython v1.25.0 on 2025-04-15; Raspberry Pi Pico2 with RP2350
Reproduction
Copy the following into wdt_lightsleep_2350.py.
from machine import lightsleep, WDT
from time import sleep_ms
wdt = WDT(timeout=5000)
lightsleep(3000)
sleep_ms(3000)
print('Should not print')
sleep_ms(3000)
Do 'mpremote run wdt_lightsleep_2350.py'.
Expected behaviour
Expect the same behavior seen when the lightsleep is replaced with sleep_ms.
File wdt_sleep_ms_2350.py
from machine import lightsleep, WDT
from time import sleep_ms
wdt = WDT(timeout=5000)
sleep_ms(3000)
sleep_ms(3000)
print('Should not print')
sleep_ms(3000)
>> mpremote run wdt_sleep_ms_2350.py
Traceback (most recent call last):
File "/home/picompute/.local/bin/mpremote", line 8, in <module>
sys.exit(main())
Note: most of traceback removed.
This time the print did not execute because the watchdog timer triggered during the second sleep_ms(3000).
Observed behaviour
The print statement does execute and the watchdog timer triggers during the last sleep_ms(3000).
>> mpremote run wdt_lightsleep_2350.py
Should not print
Traceback (most recent call last):
File "/home/picompute/.local/bin/mpremote", line 8, in <module>
sys.exit(main())
Note: most of traceback removed.
Additional Information
I have changes to lightsleep in modmachine.c which fix this problem.
I will prepare a pull request with this fix.
The root cause is the watchdog timer does not count down while lightsleep() is running.
This problem is RP2350 specific and is not seen on RP2040.
Code of Conduct
Yes, I agree
port/rp2/modmachine: Fix lightsleep watchdog interactions.
Summary
Second try at this change. I had trouble resolving a merge conflict in an earlier pull request and gave up.
Aside: I am a little hesitant to propose these changes. If the maintainers decide to reject this pull request I will understand.
Lightsleep on rp2 is gradually getting more complex and these changes would contribute to that complexity.
Fixes RP2040 issue #17228 and RP2350 issue #17229.
RP2040 issue is when watchdog timer expires while
lightsleep is running the RP2040 will lock up during power-on startup.
This occurs because the power-on state machine is configured to not re-initialize the ROSC and lightsleep stopped the ROSC.
RP2350 issue is the watchdog timer does not decrement while lightsleep is running.
Once lightsleep returns the timer will start decrementing again. This occurs because lightsleep clears the bit
CLOCKS_SLEEP_EN1_CLK_SYS_WATCHDOG_BITS while sleeping.
Testing
I ran the reproduction tests from the two issues.
I also ran tests/port/rp2/rp2_lightsleep.py.
Trade-offs and Alternatives
General alternative. Document that lightsleep and watchdog don't play well together and leave the code as is.
Alternatives for RP2040 issue #17228:
- Raise issue for pico-sdk. Get them to change function _watchdog_enable() so the ROSC and XOSC do get reset on a watchdog timeout. The existing behavior in _watchdog_enable() has been there from day one. There might not be a good reason for it. Disadvantage: a possible long wait for a new pico-sdk release.
- Modify lightsleep to not stop the ROSC. I measure 4.96 milli-amps when lightsleep disables ROSC and 5.09 milli-amps when it does not. This is a small change.
Alternatives for the RP2350 issue #17229:
- I don't have any :-).
<!-- Thanks for submitting a Pull Request! We appreciate you spending the
time to improve MicroPython. Please provide enough information so that
others can review your Pull Request.
Before submitting, please read:
https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md
https://github.com/micropython/micropython/wiki/ContributorGuidelines
Please check any CI failures that appear after your Pull Request is opened.
-->
Summary
<!-- Explain the reason for making this change. What problem does the pull request
solve, or what improvement does it add? Add links if relevant. -->
Testing
<!-- Explain what testing you did, and on which boards/ports. If there are
boards or ports that you couldn't test, please mention this here as well.
If you leave this empty then your Pull Request may be closed. -->
Trade-offs and Alternatives
<!-- If the Pull Request has some negative impact (i.e. increased code size)
then please explain why you think the trade-off improvement is worth it.
If you can think of alternative ways to do this, please explain that here too.
Delete this heading if not relevant (i.e. small fixes) -->