I’ll give that a try in Micropython today and report back!
I have some good news!! Picoware’s Micropython version works with the uf2loader without any edits needed.
v2.3 is released. USB mass storage access to the SD card when in the menu, and apps compiled as no-flash can be run without affecting the currently flashed app.
I was able to get this setup and working on a Pico 1. The USB drive addition is awesome and will be very helpful.
The version number still says v2.2
Thanks for the update!
Thanks for testing it on the pico 1, I’d hoped someone would check so I wouldn’t have to ![]()
Fixed the version number, too. Cheers.
The SD card mount is not working for me with a Pico 2W and macOS.
It would be an awesome feature!
Unfortunately there’s not much I can do to debug macOS issues right now, as I don’t have access to a mac!
It shows up as a USB Serial device on macOS and also a Windows VM with assigned access to the USB.
Make sure you’re using the micro USB port on the Pico and not the USB C port on the picocalc itself.
It is working fine under Linux. This is probably the single best feature you could have added, thank you.
Oops, I used the USB-C on the PicoCalc. But it is still not showing up using the micro USB port.
I also tried on an Intel MacBook Pro running Windows 11 under BootCamp. The “USB device was not recognized.”
Is it working for anybody on Mac?
Not seen at all on my MacBook Pro (Apple Silicon, M1 Pro). I am using a USB-C to USB-C cable with a Pimoroni Pico Plus 2W in the PicoCalc.
It is recognized on my Pi 5 (ARM) with Debian Bookworm using USB-A to USB-C.
On Windows 11 (Intel), I get “The last USB device you connected to this computer malfunctioned and Windows does not recognize it.” using USB-A to USB-C.
uf2loader did just connect to my MacBook Pro just once. I am not sure why it did and I have not been able to duplicate this.
I have noticed, both in this one connection on the MacBook Pro and on my Raspberry Pi 5 that the connection takes a while. MacOS asked me if I wanted to allow the USB device to connect, then it took say 15-30s to appear in the finder and about the same in Gnome’s file browser.
It is successfully mounting in Windows for me. And it will always be a bit slow - the pico only has full-speed (12mbit) usb, so don’t expect a lot out of it.
(discovered in the process there’s some dumb anti-linux behaviour in windows that insists on asking to format MBR linux partitions even when they’re marked hidden, so you’ll always get this if your sd card has the fuzix partition present. GPT partitions don’t do this, but uf2loader requires MBR for reasons.)
If someone has the ability to do a usb wireshark capture in the non-working case I’ll compare it to my working captures.
That’s a tough one on current macOS due to SIP and other USB protections.
I’ll have to dust off one of my development machines to do that.
i think release 2.3 might have broken compatibility with 1.4 keyboard firmware (though i’m using this custom one: Custom PicoCalc BIOS/keyboard firmware), diag_pico.uf2 bootloops with the diagnostic screen flickering on the screen for a second similarly to how the MicroPython builds have been doing
reverting to version 2.1 (both BOOTSEL and the BOOT2040.uf2 on SD) makes it work again
If it’s resetting, it’s going to be for different reasons.
And it’s very weird if it’s happening with diag. Are you loading that from the menu or did you install it via bootsel?
i’m loading the diag from bootsel, and every time i try a different version i’m both doing the loader in bootsel and the ui boot2040 on the root of the sd card. 2.1 works fine, 2.2 and 2.3 i can’t ever see the menu, the display stays off and the keyboard backlight flickers. i got the 2.3 diag to show _once _ last night (all 3 passes) and i have no idea how and it won’t do it again… i’ll keep trying and if anything changes i’ll post here
2.1 works absolutely fine and i’ve been using it since day one with my unit. i’m using a pico1
i’ve gotten 2.3 working, i’m not entirely sure what i was doing wrong, but i think it’s somewhat related to the mode where the loader will go into BOOTSEL mode if it can’t load the correct BOOT2040.UF2 from SD. most likely because of my order of operations landing in a state where i had the 2.3 bootloader and the 2.1 menu UF2 during one of the loop cycles until i had both updated, which might’ve corrupted things?
making sure the bootloader never started without the SD or with the wrong version menu on first run (put menu on SD first, insert SD and only then flash bootloader) worked fine, so nothing wrong on your end
i only suspected something related to the keyboard because the behaviour was quite the same as the MicroPython firmwares on 1.4 keyboard
so i switched to a Pimoroni Pico Plus 2W, and i’m wondering if this is causing some issues:
i can’t seem to get the SD card over USB mount to happen, i’m on 2.3 and i’m plugging the cable only after it’s booted and on the menu (and i’m on Windows 10 if that helps)you need to plug it into the pico, not the picocalc…
- some firmwares seem to work but others don’t, for example machikania and picoware for 2W both work, but neither picomite for 2 or webmite for 2W seem to work, and i at least got webmite to work if i flash it directly via BOOTSEL instead
ps: i’ve been poking at it some more, i think picomite 2350 doesn’t like living in the “second partition” (if i understand it right?) that the bootloader makes for firmwares? if i, all through BOOTSEL, flash the bootloader, then webmite, it doesn’t work. but if i nuke the flash and then flash webmite again, that’s when it works
not sure if it has anything to do with anything but it is worth nothing the Pico Plus 2W has 16MB flash rather than the pico 2’s 4MB