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)