I’m trying to build the Pico2 version of the uf2loader, but get an error about tusb:
[ 73%] Building C object ui/CMakeFiles/ui.dir/lib/usb_msc/usb_msc.c.o /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c: In function 'usb_msc_init': /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:3:error:unknown type name 'tusb_rhport_init_t' 23 | tusb_rhport_init_tdev_init = {.role = TUSB_ROLE_DEVICE, .speed = TUSB_SPEED_AUTO}; | ^~~~~~~~~~~~~~~~~~ /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:34:error:field name not in record or union initializer 23 | tusb_rhport_init_t dev_init = {.role = TUSB_ROLE_DEVICE, .speed = TUSB_SPEED_AUTO}; | ^ /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:34:note:(near initialization for 'dev_init') /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:42:error:'TUSB_ROLE_DEVICE' undeclared (first use in this function); did you mean 'TUSB_DESC_DEVICE'? 23 | tusb_rhport_init_t dev_init = {.role =TUSB_ROLE_DEVICE, .speed = TUSB_SPEED_AUTO}; | ^~~~~~~~~~~~~~~~ | TUSB_DESC_DEVICE /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:42:note:each undeclared identifier is reported only once for each function it appears in /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:60:error:field name not in record or union initializer 23 | tusb_rhport_init_t dev_init = {.role = TUSB_ROLE_DEVICE,.speed = TUSB_SPEED_AUTO}; | ^ /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:60:note:(near initialization for 'dev_init') /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:69:error:'TUSB_SPEED_AUTO' undeclared (first use in this function); did you mean 'TUSB_SPEED_FULL'? 23 | tusb_rhport_init_t dev_init = {.role = TUSB_ROLE_DEVICE, .speed =TUSB_SPEED_AUTO}; | ^~~~~~~~~~~~~~~ | TUSB_SPEED_FULL /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:69:warning:excess elements in scalar initializer /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:23:69:note:(near initialization for 'dev_init') /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:25:3:error:too many arguments to function 'tusb_init'; expected 0, have 2 25 | tusb_init(BOARD_TUD_RHPORT, &dev_init); | ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/menadue/tree/github/uf2loader/ui/lib/usb_msc/usb_msc.c:9: /home/menadue/pico/pico-sdk/lib/tinyusb/src/tusb.h:136:6:note:declared here 136 | booltusb_init(void); | ^~~~~~~~~ make[2]: *** [ui/CMakeFiles/ui.dir/build.make:1371: ui/CMakeFiles/ui.dir/lib/usb_msc/usb_msc.c.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:2813: ui/CMakeFiles/ui.dir/all] Error 2 make: *** [Makefile:91: all] Error 2
I’m pretty sure I followed the build instructions on the github, does tusb need to be installed somewhere for the build to work?
Tinyusb is included with the pico-sdk (but as a submodule - so you might need to do a git submodule update --init --recursive in there to make sure they’re all checked out properly)
What did your cmake output look like?
I just did a fresh build from the exact same public commit and got this:
pelrun@omen:~/github/uf2loader$ cmake -S . -B build -DPICO_BOARD=pico2 --fresh
PICO_SDK_PATH is /home/pelrun/.pico-sdk/sdk/2.2.0
Target board (PICO_BOARD) is 'pico2'.
Using board configuration from /home/pelrun/.pico-sdk/sdk/2.2.0/src/boards/include/boards/pico2.h
Auto-converting non-specific PICO_PLATFORM='rp2350' to 'rp2350-arm-s'
Defaulting platform (PICO_PLATFORM) to 'rp2350-arm-s' based on PICO_BOARD setting.
Defaulting compiler (PICO_COMPILER) to 'pico_arm_cortex_m33_gcc' since not specified.
Configuring toolchain based on PICO_COMPILER 'pico_arm_cortex_m33_gcc'
Defaulting PICO_GCC_TRIPLE to 'arm-none-eabi'
-- The C compiler identification is GNU 14.2.1
-- The CXX compiler identification is GNU 14.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/pelrun/.pico-sdk/toolchain/14_2_Rel1/bin/arm-none-eabi-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/pelrun/.pico-sdk/toolchain/14_2_Rel1/bin/arm-none-eabi-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is GNU
-- Found assembler: /home/pelrun/.pico-sdk/toolchain/14_2_Rel1/bin/arm-none-eabi-gcc
Build type is MinSizeRel
Using picotool from /home/pelrun/.pico-sdk/picotool/2.2.0/picotool/picotool
-- Found Python3: /usr/bin/python3.13 (found version "3.13.7") found components: Interpreter
TinyUSB available at /home/pelrun/.pico-sdk/sdk/2.2.0/lib/tinyusb/hw/bsp/rp2040; enabling build support for USB.
BTstack available at /home/pelrun/.pico-sdk/sdk/2.2.0/lib/btstack
mbedtls available at /home/pelrun/.pico-sdk/sdk/2.2.0/lib/mbedtls
lwIP available at /home/pelrun/.pico-sdk/sdk/2.2.0/lib/lwip
PICO_BOARD: pico2
PICO_PLATFORM: rp2350-arm-s
PICO_FLASH_SIZE_BYTES: (4 * 1024 * 1024)
part_size_kb: 4088
-- Configuring done (0.5s)
-- Generating done (0.1s)
-- Build files have been written to: /home/pelrun/github/uf2loader/build
pelrun@omen:~/github/uf2loader$ cd build
pelrun@omen:~/github/uf2loader/build$ make -j
<working build output>
Check to make sure cmake is actually finding a valid 2.2.0 sdk path and not dropping back to something older.
Thanks for that. I think the problem is that I have an old SDK. I’m using that older SDK to finish some other code and don’t want to break that, so will look at putting SDK 2.2 into the uf2loader when it’s not possible to mess stuff up.
You can install different versions of the sdk in parallel.
(btw I don’t think there’s any major reason not to migrate entirely to 2.2.0 - it shouldn’t really break anything, and it does fix a bunch of bugs. But as a professional developer myself I do understand the need to lock down versions of things occasionally… if only to put off having to redo a bunch of testing!)
Yes, I saw you had a nested SDK, I’ll try the same. I have over a years work that I don’t want to disturb, been bitten by that before, so it’ll be a few days before I mess with my setup. It’ll probably be ok. Probably.
So what is the story for how different firmwares approach the extra 14MB/12MB Flash in the Pimoroni devices versus the (expected) 2MB/4MB Flash in the Picos? Are most just mounting the extra as another FS volume? Or do most just treat it as if “firmware memory pool/space” (XIP etc) is larger, but not bothering to impose FS onto the extra space?
-John
P.S. Asking because things are a bit wild-West atm, and hard to get a sense of which is “winning”. Making both extra Flash and PSRAM as volumes feels “a bit much”, would rather leave PSRAM as potential heap or whatever if possible. Maybe best to enable Arduino-like earlyboot pref choice of balance between “Flash memory pool”/”Flash-as-FS”? Just thinking out loud.
Depends on the application. In general, everything is using the PICO_FLASH_SIZE_BYTES macro to determine at compile time how much space is available, and doing whatever with it (fs, raw data blocks, etc). If you put a binary on a device with a larger flash, the remaining space will go completely untouched, and if you put it on a smaller flash, it’ll try to write to non-existent pages and will throw errors (or silently lose data).
Occasionally something will query the flash for it’s size directly - picomite did this (until I fixed it). It’s not necessarily a better approach, as there are benefits for knowing exactly what the flash layout will be for a particular build.
Hi!
I finally managed to get UF2 Loader working with a Pico 2040 (I have a Pico 2350W, and with that one… things didn’t go well).
I can select UF2 images, and most importantly, PicoMite runs fine, so I can keep using the hundreds of scripts I wrote before.
Now I’m trying to install MicroPython, but I haven’t been able to. I downloaded the version for Pico 2040 from this link:
But when I select that image at boot, it starts writing to flash and halfway through I get the error “ERR: Bad UF2 file” around block 1500 of 7xxx total.
Has anyone run into this? Any idea how to fix it?
Thanks in advance, and congratulations @pelrun on creating such a powerful tool!
Now I’m trying to install MicroPython , but I haven’t been able to…
But when I select that image at boot, it starts writing to flash and halfway through I get the error “ERR: Bad UF2 file” around block 1500 of 7xxx total.
Bit of a silly question. How do I remove uf2loader? Do i just flash a ‘normal’ uf2 over it?
I’m asking because I have flashed my modified uf2loader onto my Pimoroni Pico Plus 2 and it didn’t work. I then flashed my app and all seemed fine, but the USB doesn’t work. It was before I did this, so I’m wondering if the uf2loader leaves something behind?
Yes, with a small caveat on the Pico2. The rom bootloader understands the partition table that uf2loader installs, so just copying a uf2 to the drive (or loading it with picotool) will put it in the app partition and leave uf2loader installed. Good in most cases except yours!
So you’ll need to erase the flash to clear the partition table first - picotool erase -a or flash_nuke will do the job.
Nah, that’s mostly a relic from before I started working on the codebase - since it includes the usb or uart stdio stuff, it bloats the bootloader beyond what fits in it’s partition.
Partly this is also why diag exists - it’s basically same code the bootloader does, just as an app and with lcd output.
The standard build leaves the debug symbols in the .elf, so proper gdb debugging is what I normally use.
I never figured out how zenodante generated those uf2’s - it’s not documented, and they must have manually patched together a couple of binary blobs, because the seam between the two isn’t correct. This is what uf2loader complains about, and while I did put in a specific workaround for a particular type of poorly formed uf2, this went beyond what I was comfortable with.
I was going to figure out how to build micropython properly myself but haven’t had the time.
SUCCESS!!! Thanks to the latest source firmware of Picomite from @pelrun, I was able to use UF2 Loader to bring up WebMite on my PicoCalc. It can be done! I’m using v6.01.00b10 for the WebMite RP2350A firmware.
In desperation, I tried to go back to the original SD boot loader, the bin files conversions were such a compromise… but when I couldn’t get WebMite working on that, I was about to give up on SD card loading until I saw those new code releases. Exciting times ahead, and thanks to everyone who keeps working on this platform. Cheers!!!
@9a4db, the credit goes to @pelrun with his latest “UF2loader fixed build” release, found on his github “PicoMiteAllVersions” repo. Be sure to also follow the directions on his “uf2loader’ repo, to get everything synched up.