Unable to mount CIRCUITPY drive from Pico W after accessing wifi.

[BiffoBear]

CircuitPython version

Adafruit CircuitPython 8.0.0-beta.2-9-g5192082e6 on 2022-10-16; Raspberry Pi Pico W with rp2040
Board ID:raspberry_pi_pico_w

Code/REPL

import wifi

wifi.radio.connect("SSID", "Password")

Behavior

Running code that does not connect to wifi does not cause a problem. After running code that connects to wifi (without raising any exception) when I dismount the CIRCUITPY volume, I cannot remount it. I have to nuke the flash and reinstall CircuitPython to mount the CIRCUITPY volume. I get the same behavior when attempting to mount the volume on a Mac and a Raspberry Pi. On the Raspberry PI, lsusb hangs until I unplug the Pico W.

Description

No response

Additional information

No response

[Neradoc]

I get a similar behavior on picoW with an empty code.py, on Mac, but I was not able to find a way to reproduce the problem consistently. After pressing reset:

• sometimes the board shows up on USB.
• sometimes it doesn't.

When it doesn't come back, the code isn't running (at least with a code that blinks the LED). Booting in safe mode seems to always make the board come back. I can't reproduce the issue on a pico.

[bill88t]

Confirmed the bug. Though I experienced some different results. Serial was also inaccessible. lsusb was hanging alright.

Though sometimes it just appeared fine.

Usb negotiation seems to fall apart due to the lag of connecting to the wifi. Journal:

xhci_hcd 0000:01:00.0: ERROR: unexpected setup address command completion code 0x24.
xhci_hcd 0000:01:00.0: ERROR: unexpected setup address command completion code 0x24.
usb 1-1.2: device not accepting address 10, error -22

[bill88t]

This bug will only appear on VERY early wifi connections. Under something like ljinux which does it like 5s in the boot, it will never happen.

A temporary mitigation would be to just time.sleep for a while till usb has init'ed.

Also, the drive is just fine, the board is just failing usb negotiation.

[BiffoBear]

This bug will only appear on VERY early wifi connections. Under something like ljinux which does it like 5s in the boot, it will never happen.

A temporary mitigation would be to just time.sleep for a while till usb has init'ed.

Also, the drive is just fine, the board is just failing usb negotiation.

Hi Bill88t, thanks for the explanation and mitigation. you've got me progressing again!

[jepler]

Based on what you've described, I know where in the core the fix is likely to go, in case someone else wants to try picking up the issue & making a fix.

The file is ports/raspberrypi/common-hal/wifi/Radio.c in the functioncommon_hal_wifi_radio_connect. Instead of using cyw43_arch_wifi_connect_timeout_ms, it will need to be changed to use the async connect function followed by a test for the connection being established, doing some "misc stuff" like is done later on for ping:

    while (port_get_raw_ticks(NULL) < deadline && !ping_received) {
        RUN_BACKGROUND_TASKS;
        if (mp_hal_is_interrupted()) {
            break;
        }
    }

[jepler]

@bill88t please tag me if you want to pass this back, I assigned it to you based on your message on Discord :)