The RP2 bootloader could unmount itself, remount itself, and present a 'FAILED.HTM' or 'FAILED.TXT' file which explains why the UF2 had not been accepted. It would probably be best if the other files usually shown were not shown to make the failure more obvious.How would you do that?It's a shame IMO that the RP2 bootloaders don't have any means to signal "That wasn't a UF2 I could accept", likewise the command line 'picotool' which also silently fails and leaves the user in the dark as to what has happened.
For 'picotool' it can determine the device type once in BOOTSEL mode, scan the UF2 to be loaded, determine which Family ID that is for and whether it is suitable for the device connected, give a suitable error message as appropriate.
I do the latter with my 'picotool' wrapper and that has worked well so far. The RP2 bootloader is baked into silicon so we are stuck with what it does.
Or maybe not : If every UF2 generated were universal, contained a Run from RAM program which runs on the opposite device to what the UF2 is intended for, that would always get loaded and run when the upload completes and that could create the virtual disk which gets mounted and reports a failure.
Statistics: Posted by hippy — Wed May 14, 2025 8:10 pm