"No drive to deploy" but on Windows - not Linux

[guidol70]

Since the last revisions of the RP2040 Core I got the problem on Windows 10 64Bit with Arduino IDE 1.8.19 that after compiling the Arduino IDE is reseting my Pico to UF2 state
(Upload Method Default UF2 and using COM-Port (COM19:) - also a PicoW at COM3: has that problem -
but then when it should upload it doesnt find the UF2-device:

C:\Users\guido\AppData\Local\Arduino15\packages\rp2040\tools\pqt-python3\1.0.1-base-3a57aed-1/python3 -I C:\Users\guido\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\4.1.1/tools/uf2conv.py --serial UF2_Board --family RP2040 --deploy C:\Users\guido\AppData\Local\Temp\arduino_build_18777/TEST.ino.uf2 
Resetting COM19
Converting to uf2, output size: 353280, start address: 0x2000
Scanning for RP2040 devices
No drive to deploy.
An error occurred while uploading the sketch

After the soft-reset from the Arduino IDE I can see the Pico in the FileExplorer as Drive/UF2-Mode (F:)

Additionally when setting the Pico before compile/upload to UF2-Mode and using UF2-Device instead of COM-Port then the Arduino IDE take a very long time (1-2 Minutes?) until it finds the UF2-device and then flash it in a few seconds (blink of an eye).

Is there any setting to control for the timeout of a soft-reseted Pico or can I enable a log to see why the search does take so long? Maybe the soft-reseted Pico runs in a timeout againt a pre-UF2 device?

BTW: Programming the Pico via Drag&Drop the UF2 to the F: Drive does work without any flaw.

Scanning for RP2040 devices
Flashing F: (RPI-RP2)
Wrote 353280 bytes to F:/NEW.UF2

Upload-Setting in Tools - I do use:

[maxgerhardt]

The timeout is already set for 10 seconds, so the drive should appear in that timespan after the COM port was reset (1200bps touch).

arduino-pico/tools/uf2conv.py

Lines 416 to 422 in 2324d52

	print("Scanning for RP2040 devices")
	sys.stdout.flush()
	now = time.time()
	drives = []
	while (time.time() - now < 10.0) and (len(drives) == 0):
	time.sleep(1.0) # Avoid 100% CPU use while waiting for drive to appear
	drives = get_drives()

For Windows, it tries to execute these commands to capture the drive list:

arduino-pico/tools/uf2conv.py

Lines 248 to 262 in 2324d52

	try:
	r = subprocess.check_output(["wmic", "PATH", "Win32_LogicalDisk",
	"get", "DeviceID,", "VolumeName,",
	"FileSystem,", "DriveType"])
	except:
	try:
	nul = open("nul:", "r")
	r = subprocess.check_output(["powershell", "-NonInteractive", "-Command",
	"Get-WmiObject -class Win32_LogicalDisk | "
	"Format-Table -Property DeviceID, DriveType, Filesystem, VolumeName"],
	stdin = nul)
	nul.close()
	except:
	print("Unable to build drive list");
	sys.exit(1)

Maybe a way to debug this would be to make the script print() the output from the commands, plus if the drive passes the filter test at the bottom?

[earlephilhower]

Nothing on the upload side has changed in a long time. The upload script was last edited 8 months ago (a Python3 lint warning fix, not logic) according to git, and the Windows Python3 version we use is 5 years old at this point. So this leads me to think that something on the specific PC's end has changed. (Note that uploads won't work if your Pico has crashed or hung...it needs to be working to respond to the USB reset request).

If you have checked things and aren't seeing anything obvious, the fastest way forward is to use the picotool upload method from the menus. That adds a new USB interface after the 1st upload which doesn't depend on Windows' automount or antivirus options.

[guidol70]

@maxgerhardt
The timeout the the uf2conv.py did lead me in the right direction ;)
When I did set the timeout from 10 to 200 seconds then the flash does work (after 1-2 minutes) like when the Pico is right from the start in UF2-Boot-Mode.
(also deactivating the sleep command in the uf2conv.py doesnt set the CPU to 100%)

So like @earlephilhower mentioned the problem has to be on my (this specific) pc.
I remembered that the desktop icon refresh is slow and also the file explorer sometimes take a good while for reacting :(

I didnt think about this in the frist place, because in the last time it did react better than before.
After a new search in the net I did some suggestions to speedup file interaction:

• clear the icon cache
• remove files from TEMP-directory
• clear/cleanup desktop (remove "real" data and only have icon-links on the desktop)

but this seems to have only a small effect :(
On some internet-pages I did read about that SMB-Network-drives do slow doen Windows 10..

So I

• disconnected all SMB-Drives in the File-Explorer
• removed all mapped-drives-entrys in the registry
• deinstalled the now useless SMBv1-Client in the Windows-Features
  and rebooted.

After the reboot I did compile in the Arduino IDE and now the UF2-Drive was found (fast like in the past in around 2 seconds after soft-reset) and flashed.

For testing I reconnted all of my SMB-Network-drives and the delay in the Arduino IDE is gone.
Have to check if the SMB-Network-drives also will be act faster in the future.

I personally think now, that it was a "hanging" (not connected/found and not displayed) SMB-Network-drive connection which resulted in a long timeout - which was to long for the Arduino IDE.

I will have an eye for the time being used while flashing Picos or using the FileExplorer/Desktop to see that the problem has (after a long time) solved :)