QUERY · ISSUE

WLAN functions fail on Pico Pi W core1

openby ayjaymopened 2023-07-09updated 2023-11-03

bugport-rp2

Reproducible on 1.20 and latest nightly build (as of today)
Attempting to set up the Wifi module on core1 fails at the line ap.active(True) below which hangs. Code works fine on core0
Guarding code with a lock does not resolve the issue.

ssid = 'MicroPython-AP'
password = '123456789'
ap = network.WLAN(network.AP_IF)
ap.config(essid=ssid, password=password)
print("status = ", ap.status())
ap.active(True)
print(ap.ifconfig())

CANDIDATE · ISSUE

Pico W port Wifi Problems

closedby edmcmanopened 2024-12-25updated 2024-12-29

bug

Port, board and/or hardware

RP2040 on Raspberry Pi Pico W

MicroPython version

(sysname='rp2', nodename='rp2', release='1.24.1', version='v1.24.1 on 2024-11-29 (GNU 13.2.0 MinSizeRel)', machine='Raspberry Pi Pico W with RP2040')

Reproduction

Clone https://github.com/edmcman/rpi-temp-server/tree/debug
Edit SSID/password in main.py
Run pipkin --port /dev/ttyACM0 install -r requirements.txt
Edit the IP address in test.bash to batch the Pico W's IP
Run test.bash a bunch of times.

Expected behaviour

The test.bash script tests whether the web server remains accessible after progressively longer periods of times with no requests. It is expected that the web server will remain available and the script will print "Test succeeded".

Observed behaviour

When run 20 times with a limit of 2048 second periods, 8 out of the 20 runs failed, meaning that the web server became inaccessible. Here is a breakdown of the power modes during failures:

fgrep -l -R Fail *.log | xargs fgrep Random | awk '{print $4}' | sort | uniq -c
      6 network.WLAN.PM_POWERSAVE
      2 None

And the overall distribution of tested pm values:

      2 0xa11140
      8 network.WLAN.PM_NONE
      1 network.WLAN.PM_PERFORMANCE
      7 network.WLAN.PM_POWERSAVE
      3 None

I am not sure why they are so uneven.

Additional Information

High level problems

I think there are two problems:

The default PM value may not be ideal. My testing suggests that network.WLAN.PM_NONE may be more reliable.
The fact that the Pico W reports it is still connected and can't reconnect is very problematic.

Other Information

When the Pico W becomes inaccessible, the logs contain the following messages repeated very often:

[ 2509685] ASYNC(0000,49,0,0,0)

It is unclear what the 49 message is. Under normal operation, it appears to be correlated with PSK_SUP messages. But as soon as it starts repeating by itself the Pico W is offline.

Also, an asynchronous task that calls WLAN.isconnected() and WLAN.status() shows that the Pico W is connected, even though it does not seem to be:

[snip]
[ 3505634] ASYNC(0000,49,0,0,0)
[ 3507681] ASYNC(0000,49,0,0,0)
[ 3508397] ASYNC(0000,49,0,0,0)
Still checking Wi-Fi connection...
Debug: connected: True status: 3
Actual PM: 0xa11142

Here is a zip file of my collected logs:
logs-2048.zip

I am currently conducting more and longer tests to hopefully provide more information. In theory, if PM_NONE proves more reliable, changing the default to help a lot in practice. But even the current behavior for other power management modes is very concerning as it means long term connections are basically impossible.

Code of Conduct

Yes, I agree