8000 Raspberry Pi Pico W network becomes inaccessible when not used for some time · Issue #9455 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Raspberry Pi Pico W network becomes inaccessible when not used for some time #9455

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
anecdata opened this issue Sep 28, 2022 · 7 comments
Open

Raspberry Pi Pico W network becomes inaccessible when not used for some time #9455

anecdata opened this issue Sep 28, 2022 · 7 comments
Labels
bug

Comments

@anecdata
Copy link
anecdata commented Sep 28, 2022 •
edited
Loading

Using MicroPython v1.19.1 on 2022-09-20; Raspberry Pi Pico W with RP2040, Pico W loses network operation (though seemingly not AP connection since there is typically still an IP address) if no network operations are performed for some time. The maximum non-operating interval between network operations is typically about 5 minutes with Power-Saving on, and at least 10 minutes with Power-Saving off (more testing continues with this mode). The failure mode is typically OSError: -2.

If some operation, say a ping is done frequently, the network operation is preserved and more complex transactions (e.g., sockets) can be done with much longer intervals.

Code:

import time
import machine
import network
import urequests as requests

TEXT_URL = "http://wifitest.adafruit.com/testwifi/index.html"

wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect("ssid", "passw0rd")
while not wlan.isconnected() and wlan.status() >= 0:
    print(f"Connected? {wlan.isconnected()} Status? {wlan.status()}")
    time.sleep(1)
print(wlan.ifconfig()[0])

# increase delay between requests each time
interval_sec = 0
increment_sec = 60
timer_sec = time.time() - interval_sec
while True:
    if time.time() - timer_sec > interval_sec:
        try:
            r = requests.get(TEXT_URL)
            print(f"{interval_sec:>5} {r.status_code} {r.reason.decode()} {r.content}")
            r.close()
            interval_sec += increment_sec
        except OSError as e:
            print(e)
            machine.reset()
        timer_sec = time.time()

Output:

Connected? False Status? 1
192.168.6.198
    0 200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)'
   60 200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)'
  120 200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)'
  180 200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)'
  240 200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)'
-2

Possibly related to power-saving mode (wlan.config(pm = 0xa11140)) described in section 3.6.3 here.

Documented here and here.

Addendum: Pinging the device periodically from an external source also seems to extend accessibility of the network.

Addendum 2: Toggling the LED via the wifi module gives mixed results keeping the network alive, other factors may be at work. But the early test with network failure in Power-Saving off mode was perhaps spurious. A subsequent run has shown a longer interval possible between network operations.

The SDK doc indicates "Both the low level cyw43_driver and the lwIP stack require periodic servicing" (p.265), but it's not clear to me what those intervals are or how to recover the network from lack of servicing without a hard reset of the board after an OSError: -2.
@anecdata anecdata added the bug label Sep 28, 2022
@anecdata anecdata mentioned this issue Sep 28, 2022
Closed
@jepler
Copy link
Contributor
jepler commented Oct 1, 2022

Based on our testing, we've arranged to "default" to power saving mode of 0xa11140 in circuitpython.

@anecdata
Copy link
Author
anecdata commented Oct 1, 2022 •
edited
Loading

Also, to clarify the original comment... it does seem to be typically a disconnection from the wifi AP when using the default power-save mode. The presence of an IP address when not connected was confusing.

wlan.status() of 3 means:
#define CYW43_LINK_UP (3) Connect to wifi with an IP address
(as opposed to
#define | CYW43_LINK_NOIP (2) Connected to wifi, but no IP address)
but the device will still have an IP address even when it has become disconnected (and across restarts). Is this intended, or should that be filed as a separate issue?

@peterhinch
Copy link
Contributor

I think this depends on the AP because this test runs here with yesterday's daily build with no config changes. Currently I'm seeing

 1080 200 OK b'This is a test of Adafruit WiFi!\nIf you can read this, its working :)'

I encountered something similar when developing mqtt_as. Collaborator @kevinkk525 reported a similar problem on ESP8266: after periods of inactivity it would spontaneously disconnect and the code would go through the reconnect process. This was fixed by esp.sleep_type(0). I never encountered this issue which seemed to hint at an AP connection. I'd be interested to know the mechanism :)

On the basis of the Pico W documentation (para 3.6.3) on mqtt_as I use 0xa11140 (as per @jepler ).

@anecdata
Copy link
Author
anecdata commented Oct 2, 2022

I'm interested to know the mechanism too, though I'm not too savvy to the low layer protocols. Other devices stay connected, but it's also not surprising that there would be differences in behavior across different network equipment when tweaking sleep intervals.

This was referenced Oct 4, 2022
Closed
Open
@maxi07
Copy link
maxi07 commented Oct 29, 2023

Is there any update on this? I am still having the same issue

@Martvse
Copy link
Martvse commented Oct 29, 2023

I am also experiencing this problem, it's frustrating.

@proxict
Copy link
proxict commented Nov 2, 2023

I'm running into the same problem with the C API. That makes me believe the problem is more low-level and not in the micropython bindings.

@anecdata anecdata mentioned this issue Apr 11, 2025
Closed
@bty-1 bty-1 mentioned this issue May 14, 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
6 participants
@jepler @maxi07 @peterhinch @anecdata @proxict @Martvse
0