8000 RP2040 Watchdog and lightsleep issue · Issue #17228 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

RP2040 Watchdog and lightsleep issue #17228

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
cpottle9 opened this issue Apr 30, 2025 · 0 comments
Open

RP2040 Watchdog and lightsleep issue #17228

cpottle9 opened this issue Apr 30, 2025 · 0 comments
Labels
bug

Comments

@cpottle9
Copy link
Contributor
cpottle9 commented Apr 30, 2025 •
edited
Loading

Port, board and/or hardware

Raspberry PI Pico

MicroPython version

MicroPython v1.25.0 on 2025-04-15; Raspberry Pi Pico with RP2040

Reproduction

Test file named wdt_lightsleep.py.

from machine import lightsleep, WDT

wdt = WDT(timeout=3000)
lightsleep(5000)

Do 'mpremote run wdt_lightsleep.py'.

>> mpremote run wdt_lightsleep.py 
Traceback (most recent call last):
  File "/home/picompute/.local/bin/mpremote", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/mpremote/main.py", line 569, in main
    handler_func(state, args)
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/mpremote/commands.py", line 463, in do_run
    _do_execbuffer(state, buf, args.follow)
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/mpremote/commands.py", line 437, in _do_execbuffer
    ret, ret_err = state.transport.follow(timeout=None, data_consumer=stdout_write_bytes)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/mpremote/transport_serial.py", line 184, in follow
    data = self.read_until(1, b"\x04", timeout=timeout, data_consumer=data_consumer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/mpremote/transport_serial.py", line 123, in read_until
    elif self.serial.inWaiting() > 0:
         ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/serial/serialutil.py", line 594, in inWaiting
    return self.in_waiting
           ^^^^^^^^^^^^^^^
  File "/home/picompute/.local/pipx/venvs/mpremote/lib/python3.11/site-packages/serial/serialposix.py", line 549, in in_waiting
    s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 5] Input/output error
>> mpremote
mpremote: no device found

Expected behaviour

Expect it to behave the same as if lightsleep were replaced with time.sleep_ms.
Call this test file wdt_sleep_ms.py

from machine import WDT
from time import sleep_ms

wdt = WDT(timeout=3000)
sleep_ms(5000)

In this case, after do 'mpremote run wdt_sleep_ms.py'.
After 3 seconds mpremote will report an OSError because the RP2040 does a soft reset.
Run mpremote again and it will connect successfully.

Observed behaviour

The RP2040 seems to get stuck. After running 'mpremote run wdt_lightsleep.py' attempts to connect running mpremote fail.
On my Raspberry Pi 4 I see an error message of 'mpremote: no device found'.

A power cycle is required to recover.

One more observation, I have a USB power meter connected between the PI 4 and RPI Pico.
Normally it reports about 19 milli-amps consumed, about 5 milli-amps while the lightsleep is running.
After the test completes it reports about 1.00 milli-amps.

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 lightsleep turns off the ROSC.
When the watchdog timeout occurs the Power-On State Machine does not re-initialize it.
This occurs because the PICO-SDK function _watchdog_enable() zero's sm_hw->wdsel bits for the ROSC and XOSC.

The behavior reported here is seen on RP2040 only.

Code of Conduct

Yes, I agree
@cpottle9 cpottle9 added the bug label Apr 30, 2025
cpottle9 added a commit to cpottle9/micropython that referenced this issue May 1, 2025
@cpottle9
port/rp2/modmachine.c: Fix lightsleep watchdog interactions.
34dd65b 
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 micropython#17228 and RP2350 issue micropython#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.

I ran the reproduction tests from the two issues.
I also ran tests/port/rp2/rp2_lightsleep.py.

General alternative. Document that lightsleep and watchdog don't
play well together and leave the code as is.

Alternatives for RP2040 issue micropython#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 micropython#17229:
- I don't have any :-).

Signed-off-by: Carl Pottle <cpottle9@outlook.com>
@cpottle9 cpottle9 mentioned this issue May 1, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@cpottle9
0