Picotool reset only really works on Raspberry Pi Pico boards

[jonathanperret]

How to reproduce

Tested on: Arduino IDE 2.3.2, arduino-pico 3.7.2, macOS 14.2 ARM.

• Plug in any RP2040 board that is not a plain Raspberry Pi Pico, and select it in the boards menu (or, use a plain Raspberry Pi Pico board but select "Raspberry Pi Pico W" as the board).
• In the Arduino IDE, create a Blink sketch.
• Select the "Picotool" upload method.
• Following the Picotools instructions in README, put the device in BOOTSEL mode manually, then do a first upload.

There's a first minor issue here (that is also present with a "Raspberry Pi Pico" board selected): the upload concludes successfully but the device does not reboot into application code. Un-plugging then re-plugging the device (without holding the BOOTSEL button) gets the LED blinking. I suspect this could be fixed by calling picotool load with the -x flag.

• Without manually putting the device back into BOOTSEL, try to do a second upload.

With the "Raspberry Pi Pico" board selected, picotool correctly reboots the device into BOOTSEL mode, uploads the code and restarts the device.
If any other board was selected for the first upload, the second upload fails with the following error:

No accessible RP2040 devices in BOOTSEL mode were found.

Analysis

Looking at the devices on the USB bus (using e.g. lsusb), the programmed board is there, including the custom reset interface that picotool should be looking for. But the PID/VID combination is not what picotool expects, causing the device to be essentially invisible to picotool.

There appears to have been some effort put into supporting custom PID/VIDs in picotool: raspberrypi/picotool#83 but so far that has not been merged.

I guess this is mainly a picotool issue, but one issue for arduino-pico is that it advertises picotool support for all boards when it really only works for plain Raspberry Pi Pico.

A potential workaround would be to use the alternative method of rebooting to BOOTSEL mode that stdio_usb supports, which is to open (and close) the serial port at 1200 baud (e.g. stty -f /dev/tty.usbmodem1401 1200 on macOS) before invoking picotool. Apparently this is what Platform.IO does?

[earlephilhower]

This is an upstream picotool issue, essentially. Basically Picotool has hardcoded settings for VID:PID to look for in the USB tree, and only the base Pico is there. There is no option to override the VID:PID, or explicitly select a bus:device w/o looking at the VID/PID. Every decive here, including the PicoW, has a unique VID:PID so the Arduino IDE (and users/vendors) can identify it.

https://github.com/raspberrypi/picotool/blob/f6fe6b7c321a2def8950d2a440335dfba19e2eab/picoboot_connection/picoboot_connection.c#L58-L82

Unfortunately there's nothing we can do here. If UF2 upload isn't working well for you, the CMSIS-DAP (Picoprobe) is your best bet. Good luck!

[jonathanperret]

Thanks for the quick feedback, it's appreciated. If I may, there are still a couple of things I feel arduino-pico could change (without waiting for a picotool update) to alleviate this issue:

• pass the -x flag to picotool load invocations, so that a Raspberry Pi Pico already in BOOTSEL mode won't hang after the upload;
• to avoid frustration for users trying this upload method with an incompatible board, remove the picotool entry from all board descriptors apart from rpipico.json, e.g. for rpipicow:

  arduino-pico/tools/json/rpipicow.json

  Line 49 in c622156

  "picotool",

• alternately, implement the "open the serial port at 1200 bps" reset method to make picotool work with every RP2040 board.

Would you be interested in PRs implementing any of these suggested improvements?