RPI pico W is not always detected as disk in Windows 10

[ok1rig]

CircuitPython version

Adafruit CircuitPython 8.0.0-beta.3 on 2022-10-20; Raspberry Pi Pico W with rp2040

Code/REPL

import time
import board
import digitalio

led = digitalio.DigitalInOut(board.LED)
led.direction = digitalio.Direction.OUTPUT

while True:
    print("test")
    led.value = not led.value
    time.sleep(1)

Behavior

Board is not always detected as disk in windows 10.

Description

• Boot works always fine, and circuit python disk is always detected after UF2 flashing reset.
• After disconnect / turn off, the board is not detected as disk in most cases
• I wrote blink script and powered board from phone charger and program runs / blink only 1 of 5-8 tries
• I was thinking about possible faulty hardware, so I flashed Adafruit CircuitPython 7.3.1 on 2022-06-22; Raspberry Pi Pico with rp2040 and windows always detects it as circuit python disk

Additional information

No response

[Cobwebblox]

I also had problems with pico w and circuitpython not connecting/showing, don't know why.

[dhalbert]

This could be an issue with utility programs on your particular Windows machine. If you could try similar things on a Mac or a Linux machine (even an RPi), that would help to narrow down the problem.

[Cobwebblox]

This could be an issue with utility programs on your particular Windows machine. If you could try similar things on a Mac or a Linux machine (even an RPi), that would help to narrow down the problem.

Do you mean thonny, explorer, both or you don't know?

[dhalbert]

I mean third-party disk utilities or anti-virus programs. See https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting for some examples of how these programs have sometimes interfered. The symptoms you list don't sound as familiar, but it would still be good to cross-check the board on a non-Windows machine or another unrelated Windows machine with different hardware and installed programs.

[Cobwebblox]

I mean third-party disk utilities or anti-virus programs. See https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting for some examples of how these programs have sometimes interfered. The symptoms you list don't sound as familiar, but it would still be good to cross-check the board on a non-Windows machine or another unrelated Windows machine with different hardware and installed programs.

I'll try to connect it to my nas with filebrowser installed i guess (docker) and see if that works.

But right now for me it is 01:24 at night.

[ok1rig]

I mean third-party disk utilities or anti-virus programs.

In my case, Pico W is not even visible in a device manager. Windows does not play the system sound that something was connected to USB. I have such feeling that sometimes board is not fully initialized.

[dhalbert]

Does it work if you connect it to a non-Windows machine?

[Cobwebblox]

Does it work if you connect it to a non-Windows machine?

For me: no, it does not show up at all in my nas (pi with docker, filebrowser), laptop (win10) or main computer (win10)

Before it at least showed up as rpi2 or something, not anymore.

[dhalbert]

If you flash the plain Pi Pico 8.0.0-beta.4, does it also show up reliably? You mentioned the plain Pico 7.3.3 above.

It could still possibly be a hardware problem, but related to the Wifi coprocessor. Another test would be to load MicroPython for Pico W and see how reliable that is. But that does not present a disk drive, so you'd just want to see if the serial connection appears.

@jepler is there any startup thing for the CYW43 that might get stuck?

[jepler]

The early init for cyw43 is supposed to be able to return an error, but if it's going deeply wrong I don't know what actually happens:

    #if CIRCUITPY_CYW43
    never_reset_pin_number(23);
    never_reset_pin_number(24);
    never_reset_pin_number(25);
    never_reset_pin_number(29);                                                 
    if (cyw43_arch_init()) {                                                    
        serial_write("WiFi init failed\n");                                     
    } else {                                                                    
        cyw_ever_init = true;                                                   

cyw43_arch_init "Returns 0 if the initialization is successful, an error code otherwise"

subsequent to that, there is a level-triggered interrupt, handled purely within the sdk code. If something goes wrong there, the interrupt servicing routines might never finish.

But if the device can't reliably be put into bootloader mode to flash a fresh uf2, that tends to point at something other than the code on the flash device. If the boot button is held at power-on time then no code from flash is being executed yet. nothing would talk to the cyw43 chip, etc.

[dhalbert]

I think the bootloader may be working but CircuitPython startup is not. @ok1rig if you put it in boot mode, does that always work? I think the original post may imply that.

[ok1rig]

I think the bootloader may be working but CircuitPython startup is not. @ok1rig if you put it in boot mode, does that always work?

• Boot mode (when boot button is pressed) works always correctly. And if I flashed UF2 v8-beta and then there is automatic reset, it always worked fine too.

You mentioned the plain Pico 7.3.3 above.

• I was desperate so I tried v7 on Pico W and flash drive worked always as expected (of course I had not wifi functionality, it was just test)

• With v8-beta, in "normal mode", board starts once upon time, does not matter if it is on PC or powered from phone charger (if I use blink code).

• I tried original MicroPython rp2-pico-w-20221102-unstable-v1.19.1-608-gb52fe52d3.uf2 and I always get serial port in device manager and then prompt in python console.

@jepler Do you know on which pin and which baud rate is serial_write("WiFi init failed\n"); available? Perhaps, I could monitor the serial port and provide more detailed information to debug this problem.

[jepler]

I don't think that serial print actually goes anywhere.

This call happens in port_init() but that's before serial_early_init(), which is the place that would enable a serial console if it was defined. (and there's no serial console defined, either)

[jepler]

I'm wondering whether init of cyw43 should be moved later, and even whether it should not be done in safe mode. but especially since it seemingly can't be re-initialized it can't go in any of the "reset" functions. I could put a "maybe init cyw43" in a few strategic places so that it happens well after startup instead of happening super super early. I'm open to ideas.

did your testing include finding out whether your device worked with the "non-W" circuitpython firmware? I guess one of your tests involved blinking the built-in LED, which of course will not be possible without the cyw43 co-processor running.

Another thing that has a low probability of helping, but will exclude the idea that something unknown in the flash is affecting behavior is using the "resetting flash memory" firmware image from raspberry pi: https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html#resetting-flash-memory -- you'd load that uf2 once then load circuitpython again. I think there's a low probability of it making a difference.

[ok1rig]

I tried flash reset with flash_nuke.uf2, but no magic happened. Symptom is the same.

did your testing include finding out whether your device worked with the "non-W" circuitpython firmware? I guess one of your tests involved blinking the built-in LED, which of course will not be possible without the cyw43 co-processor running.

I did not concentrate on non-W testing. I just tried ~10 times disconnect/connect to PC with v7 and check if in windows the flash drive appear. It always did, so I was happy about that and exclude idea I have bad hardware.

Yesterday, I found out one more thing.

1. as usually I connect USB cable of RPI-W to PC and it is not detected.
2. then I ground RUN pin (HW reset) which revives the board. Windows detects USB device. The interesting is that not always it is put to normal mode, but also to Boot mode or Safe more. (I use jumper cable, so I can produce more than one "click")

once I found this message in the terminal:
You are in safe mode because: You pressed the reset button during boot. Press again to exit safe mode.

So, it seems to me that circuit python is "lost" somewhere in boot sequence, because sometimes wifi chip is not ready yet, when RPI talks to it.

[dhalbert]

@ok1rig Did you ever test the Pico W with Pico W CircuitPython on a non-Windows machine?

[dhalbert]

I was unable to reproduce with a Pico W on a Windows 10 Dell laptop. I wonder if it is peculiar to your particular Pico W. Do you have another one or just the one?

[ok1rig]

I did not connected to non-win pc. I have another board, but it behaved the same. Boards are from very early pre-order, bottom is shown "0622" (I guess, 6th week of 2022) and then "3.15" which I do not have clue what it could be.

[dhalbert]

Mine says 0622 and 6.14.

[dhalbert]

Here is a UF2 to try with a very simple change, which just delays one second before doing cyw43_arch_init() in supervisor/port.c. @ok1rig Could you see if this makes any difference? Unzip and then load.
picow-delay-cyw43-startup.uf2.zip

[theblinkingman]

I was able to reproduce this on two other RPI Pico W with 2422 5.5 and 5.6 on them.

Using that delay startup seems to fix the issue.

[dhalbert]

Using that delay startup seems to fix the issue.

Very interesting! @jepler This was a crude attempt at narrowing down the problem. A one second delay is long and could probably be reduced. It may simply be a power-up race condition. You probably have a better idea of what to do here. I wish we had at least one board sample that shows this problem, but neither you nor I seem to have one.

[dhalbert]

@jepler The key test I think is to see whether it comes up when plugging in. Maybe you do have a sample that shows this issue but rarely unplug and replug so you don't see it?

[ok1rig]

Here is a UF2 to try with a very simple change, which just delays one second before doing cyw43_arch_init() in supervisor/port.c. @ok1rig Could you see if this makes any difference? Unzip and then load. picow-delay-cyw43-startup.uf2.zip

This firmware works for me, circuit python drive is now recognized 10 of 10 on my problematic board.

[jepler]

I'm trying to understand what is supposed to be required by the hardware. I found a boot-up sequence timing diagram in https://www.infineon.com/dgdl/Infineon-CYW43439-DataSheet-v03_00-EN.pdf?fileId=8ac78c8c8386267f0183c320336c029f page 24

[jepler]

cyw43-driver implements the algorithm to poll for predefined pattern:

        cyw43_spi_gpio_setup();
        cyw43_spi_reset();
                                        
        // Check test register can be read
        for (int i = 0; i < 10; ++i) {
            uint32_t reg = read_reg_u32_swap(self, BUS_FUNCTION, SPI_READ_TEST_REGISTER);
            if (reg == TEST_PATTERN) {
                goto chip_up;
            }
            cyw43_delay_ms(1);
        }
        CYW43_DEBUG("Failed to read test pattern\n");

sdk spi_reset controls the WL_REG_ON pin and the delay of 250ms is much larger than the time from WL_REG_ON to WL_IRQ being asserted: (and the 20ms sleep is much larger than 2 sleep clock cycles, 61.25us at 32.768kHz) (and it seems to be permitted to SPI poll even before WL_REG_ON)

// Reset wifi chip
void cyw43_spi_reset(void) {
    gpio_put(WL_REG_ON, false); // off  
    sleep_ms(20);
    gpio_put(WL_REG_ON, true); // on
    sleep_ms(250);

    // Setup IRQ (24) - also used for DO, DI
    gpio_init(IRQ_PIN);
    gpio_set_dir(IRQ_PIN, GPIO_IN);
}

For that matter, the pico-examples call cyw43_arch_init right at the top of main without an explicit delay:

int main() {
    stdio_init_all();

    if (cyw43_arch_init()) {
        printf("failed to initialise\n");
        return 1;
    }

I don't doubt what's being reported, and we have the option of moving the initialization later (for instance after the safe-mode check, which waits 1s) but I'd like to understand why it makes a difference.

[dhalbert]

From the timing diagram, looks like 85 msecs or so? So maybe could use a 100msec delay before the startup. That's short in the scheme of things. Could note whether safe-mode delay actually happens and act accordingly, but a 100msec delay is simple for now. The reporters here will need to re-test.

[jepler]

There's already a 250ms sleep after turning on the regulator though: sleep_ms(250);. Unless we're messing with the regulator state accidentally somewhere.

[jepler]

.. and waiting with the regulator off shouldn't be able to help anything, if it's about the time from reset to usability of the cyw43 chip

[theblinkingman]

To add to the confusion, I can only reproduce the problem with the released beta.4 (Adafruit CircuitPython 8.0.0-beta.4 on 2022-10-30), but when I built from source (Adafruit CircuitPython 8.0.0-beta.4-65-g082b0d1ae from git checkout 082b0d1) it works fine. I did build debug so there might still be some timing changes, but there might be other variables too.

[jepler]

This zip has a uf2 file I builtfrom the official pico-examples. git describe --tags of pico-examples shows sdk-1.4.0-7-g8be18f2. pico-sdk used was 1.4.0. It was configured with cmake -DPICO_STDIO_USB=ON -DPICO_BOARD=pico_w -DPICO_SDK_FETCH_FROM_GIT=1.

picow_wifi_scan_poll.zip

If you have an affected device, please try copying this example to your RPI-RP2. When you plug the device in, it should present as a USB CDC (serial terminal) device, and every 10 seconds or so it should print the result of a wifi scan to the serial connection.

If the problem reproduces then it is either a HW problem or a pico-sdk bug. If the problem doesn't reproduce, it means we should look more closely at what circuitpython may be doing differently than pico-examples.

[jepler]

@theblinkingman @ok1rig I tested several pico w samples (0622 4.8, 3.9, and 1.14) but didn't reproduce the problem either with CircuitPython or with the pico examples. Can either of you try the example on your affected board and report back what happens?

[theblinkingman]

This zip has a uf2 file I builtfrom the official pico-examples. git describe --tags of pico-examples shows sdk-1.4.0-7-g8be18f2. pico-sdk used was 1.4.0. It was configured with cmake -DPICO_STDIO_USB=ON -DPICO_BOARD=pico_w -DPICO_SDK_FETCH_FROM_GIT=1.

picow_wifi_scan_poll.zip

If you have an affected device, please try copying this example to your RPI-RP2. When you plug the device in, it should present as a USB CDC (serial terminal) device, and every 10 seconds or so it should print the result of a wifi scan to the serial connection.

If the problem reproduces then it is either a HW problem or a pico-sdk bug. If the problem doesn't reproduce, it means we should look more closely at what circuitpython may be doing differently than pico-examples.

This uf2 works fine for me.

[tannewt]

This sounds like this issue: micropython#8904

[jepler]

If the analysis in that other PR ("it looks like the wireless firmware is being loaded during USB device enumeration") is correct, I do not think they would be the same cause.

In CircuitPython, we load the firmware during port_init which I think is before USB enumeration can possibly occur (usb_init is called later in supervisor_workflow_start)