He's saying that the bootloader is in ROM so it's unbrickable, but the application code that the bootloader jumps into can be updated over USB. Most mid-range and higher microcontrollers have a similar feature, but they almost always have a custom protocol that requires a specialized flashing program rather than showing up as a mass storage device.
To be frank, I don't get its appeal at all. Most hobbyist uCs were already unbrickable, and using mass storage mode for flashing is rather cumbersome and clunky to automate as soon as you're past hello worlds.
Hence they made the Pico Debug Probe [0]. It makes it super easy to reflash firmware to the Pico in a quick iterative loop.
However, the appeal of mounting as a mass storage device is not for iterative development (as you mentioned). Invariably something breaks, and the easiest way to get back on track is to reflash their default blank firmware using the mass storage interface.
I can use things like dfu-util or esptool for quick iterative loops without any additional hardware. Hence my point - mass storage is a downgrade over what other µCs on the market were already doing with their ROM bootloaders before RP2040.
Just to note: with the RP2040 you don't need additional hardware (debug probe) for quick iterative development, you can use picotool[1] (using -f allows you to flash and reboot without needing to get it to bootsel mode).
...and it doesn't use mass storage at all, blocking access to it in a clunky way to prevent simultaneous usage.
UMS seems like a nice idea when you first hear about it, but it doesn't really offer much once you look at it closer. The only proper argument for it is "no special software needed", but it a world where picotool is `apt install picotool` away that's not very advantageous anyway and only causes automount annoyances.
UMS shines where you have a device with a filesystem in its flash that you can access to actually manage the files stored there. Super useful for stuff like MicroPython. In contrast, pseudo-mass storage like on RP2040 doesn't seem very useful at all. It makes it appear more approachable, but only superficially.
The whole UF2 idea has to do with the educational background of RaspberryPi. The protocol was invented by Microsoft for use in some kind of similar educational board with the express purpose of not needing drivers, being reasonably crossplatform and crucially not needing any special permissions to access the device. The end result is that in some kind of educational setting you can use some kind of cloud/remote IDE on iPad, stick the RPi-Pico into the iPad and flash it, no blessing from Apple needed.
Oh. So it's just a result of locked-down walled gardens being so widespread that they influence the world around them. Depressing, but thank you for pointing it out anyway; on my phone I can just run picotool itself and it's easy to forget how dystopian it all got outside of the niche I'm in.
I've never had great luck with the mass storage flashing. It works fine, but boy is it slow. I bought a J-Link a few years ago and haven't looked back.
(It just takes a long time for the OS to recognize a USB device. And you have to press the reset button yourself in order to enter the bootloader. With something like J-Link, your build script can handle pressing the reset button and sending the code, saving you quite a bit of time between iterations.)
A debug probe is nice (quite possibly a must) if you're actively developing, but for deploying in a hobbyist environment, USB is hard to beat.
I make open source espresso machine hardware (github.com/variegated-coffee), and it's nice to be able to give users a wired way to update firmwares that doesn't require extra hardware.
I completely agree that it's inconvenient as a developer tool, a debug probe is much, much nicer.
I just think that despite all testing and care bugs are still possible, and the ROM bootloader is a backup that's always there. Plop a tiny switch on the PCB, and even if I screw up an OTA update customers will still be able to flash with no special tools (if the device has a USB port, that is).
I also use it as a recovery state for panics, makes the device impossible to brick by a panic loop.
> I just think that despite all testing and care bugs are still possible, and the ROM bootloader is a backup that's always there.
That's orthogonal to mass storage mode. ROM bootloaders were standard in this class of microcontrollers for years, but they usually don't use UMS. One could argue that UMS is perhaps better than some custom incompatible solutions, but then that's what DFU is there for - a standard way to flash things over USB.
Interesting, I've got the exact opposite experience.
Small to medium production runs are always a bit of a pain, because you have to do a lot of coordination with the factory when it comes to tooling. You have to ship a custom programmer, get them to install the drivers on whatever OS they are using, and then find a way to write custom code to interact with the programmer and deal with all the possible error conditions.
The RP2040? A simple script which detects the presence of a RPI-labelled flash drive, copies a file, and repeats. Written in half an hour. Drivers? Not an issue. Hardware? Everyone has a USB cable lying around already. Error conditions? It either succeeds, or it doesn't - the OS handles the rest.
