Add support for bootsel activity LED by will-v-pi · Pull Request #316 · raspberrypi/picotool

will-v-pi · 2026-05-29T15:19:46Z

Can use --led and --active-low arguments with picotool commands that reboot the device to bootsel mode (ie reboot -u and forced commands), and can also set default LED with DEFAULT_BOOTSEL_LED to always flash that LED even when --led isn't passed

Also add a section to BUILDING.md about the various supported CMake variables that can be used to customise the build

Can use --led and --active-low arguments with picotool commands that reboot the device to bootsel mode (ie `reboot -u` and forced commands), and can also set default LED with DEFAULT_BOOTSEL_LED to always flash that LED even when --led isn't passed

lurch · 2026-05-31T10:34:00Z

+- `GENERATE_FIXED_DOCS_WIDTH`: By default the width of the output from `picotool` adjusts to the width of the terminal. Setting this to `true` fixes the width to 140, which is used when generating the [README](README.md).
+- `DEFAULT_BOOTSEL_LED`: This can be used to set the default value for the `--led` argument, so `picotool` always reboots devices to BOOTSEL with that LED flashing.
+- `PICOTOOL_NO_LIBUSB`: By default `picotool` is compiled with USB support if libusb is found. Setting this to `true` explicitly compiles without USB support, which is used when the Pico SDK builds picotool.
+- `USE_PRECOMPILED`: By default the build uses pre-compiles ELF/BIN files for code that is run on the device (enc_bootloader, xip_ram_perms, and picoboot_flash_id). Setting this to `false` re-compiles these files instead.


Suggested change

- `USE_PRECOMPILED`: By default the build uses pre-compiles ELF/BIN files for code that is run on the device (enc_bootloader, xip_ram_perms, and picoboot_flash_id). Setting this to `false` re-compiles these files instead.

- `USE_PRECOMPILED`: By default the build uses pre-compiled ELF/BIN files for code that is run on the device (enc_bootloader, xip_ram_perms, and picoboot_flash_id). Setting this to `false` re-compiles these files instead.

lurch · 2026-05-31T10:37:21Z

+- `PICOTOOL_NO_LIBUSB`: By default `picotool` is compiled with USB support if libusb is found. Setting this to `true` explicitly compiles without USB support, which is used when the Pico SDK builds picotool.
+- `USE_PRECOMPILED`: By default the build uses pre-compiles ELF/BIN files for code that is run on the device (enc_bootloader, xip_ram_perms, and picoboot_flash_id). Setting this to `false` re-compiles these files instead.
+
+These can all be set by passing `-DNAME=VALUE` to your `cmake` command (e.g. `-DGENERATE_FIXED_DOCS_WIDTH=1`).


Here you've got -DGENERATE_FIXED_DOCS_WIDTH=1, but a few lines earlier you said "GENERATE_FIXED_DOCS_WIDTH: ... Setting this to true ...".

If this is a case of "CMake treats 1 as true and 0 as false", then perhaps it makes sense to change the earlier phrasing to "Setting this to 1 ..." ?

lurch · 2026-05-31T10:43:02Z

+
+These can all be set by passing `-DNAME=VALUE` to your `cmake` command (e.g. `-DGENERATE_FIXED_DOCS_WIDTH=1`).
+
+Note that the behaviour when setting `PICOTOOL_NO_LIBUSB` or `USE_PRECOMPILED` is undefined when using an existing build directory, due to the use of CMake external projects - instead you should create a new build directory to ensure it is in the correct state.


Perhaps this would be clearer as:

Suggested change

Note that the behaviour when setting `PICOTOOL_NO_LIBUSB` or `USE_PRECOMPILED` is undefined when using an existing build directory, due to the use of CMake external projects - instead you should create a new build directory to ensure it is in the correct state.

Note: when setting `PICOTOOL_NO_LIBUSB` or `USE_PRECOMPILED` you should create a new build directory (rather than using an existing build directory), due to the way `picotool` uses external CMake projects.

rather than talking about "undefined behaviour"?

lurch · 2026-05-31T10:44:51Z

+The `picotool` build has some CMake variables you can use to customise how the build works, and how `picotool` functions:
+
+- `GENERATE_FIXED_DOCS_WIDTH`: By default the width of the output from `picotool` adjusts to the width of the terminal. Setting this to `true` fixes the width to 140, which is used when generating the [README](README.md).
+- `DEFAULT_BOOTSEL_LED`: This can be used to set the default value for the `--led` argument, so `picotool` always reboots devices to BOOTSEL with that LED flashing.


Should there also be a DEFAULT_BOOTSEL_LED_ACTIVE_LOW ? 🤔

lurch · 2026-05-31T10:46:17Z

            command (unless the command itself is a 'reboot') the device will be left connected and accessible to picotool, but without the
            USB drive mounted
+        --led <led>
+            Flash LED on this GPIO to show BOOTSEL activity (ignored by Arm RP2350-A2) - only applicable if this command reboots the device


Maybe?

Suggested change

Flash LED on this GPIO to show BOOTSEL activity (ignored by Arm RP2350-A2) - only applicable if this command reboots the device

Flash LED on this GPIO to show BOOTSEL activity (ignored by RP2350-A2 in Arm mode) - only applicable if this command reboots the device

lurch · 2026-05-31T10:46:49Z

+            Flash LED on this GPIO to show BOOTSEL activity (ignored by Arm RP2350-A2) - only applicable if this command reboots the device
+            to BOOTSEL mode
+        --active-low
+            The BOOTSEL activity LED is active low (ignored on RP2040 and RP2350-A4)


Suggested change

The BOOTSEL activity LED is active low (ignored on RP2040 and RP2350-A4)

The BOOTSEL activity LED is active low (ignored by RP2040 and RP2350-A4)

For consistency with the previous option 🙂

lurch · 2026-05-31T10:51:36Z

            Force a device not in BOOTSEL mode but running compatible code to reset so the command can be executed. After executing the
            command (unless the command itself is a 'reboot') the device will be left connected and accessible to picotool, but without the
            USB drive mounted
+        --led <led>


Would it be possible to instead show

Suggested change

--led <led>

--led <gpio>

?

Although thinking about it some more, perhaps the parameter names --led and --active-low are a little "too generic" (perhaps there might be other things which are "active low" in future?) and so --bootsel-led and --bootsel-led-active-low would be better names? 🤷

lurch · 2026-05-31T10:53:15Z

            Force a device not in BOOTSEL mode but running compatible code to reset so the command can be executed. After executing the
            command (unless the command itself is a 'reboot') the device will be left connected and accessible to picotool, but without the
            USB drive mounted
+        --led <led>


Hmmm, does it make sense for the picotool info command to have a --led option??

lurch · 2026-05-31T10:55:13Z

        + option("--rp2040").set(settings.force_rp2040) % "Assume the device is an RP2040 - this is only required when using a custom vid/pid with an RP2040 on Windows, and is ignored on other operating systems"
        + option('f', "--force").set(settings.force) % "Force a device not in BOOTSEL mode but running compatible code to reset so the command can be executed. After executing the command (unless the command itself is a 'reboot') the device will be rebooted back to application mode" +
                option('F', "--force-no-reboot").set(settings.force_no_reboot) % "Force a device not in BOOTSEL mode but running compatible code to reset so the command can be executed. After executing the command (unless the command itself is a 'reboot') the device will be left connected and accessible to picotool, but without the USB drive mounted"
+        + (option("--led") & integer("led").set(settings.led)) % "Flash LED on this GPIO to show BOOTSEL activity (ignored by Arm RP2350-A2) - only applicable if this command reboots the device to BOOTSEL mode"


If DEFAULT_BOOTSEL_LED has been set (to a non-negative value), perhaps it would make sense to show that default value here?

lurch · 2026-05-31T11:07:18Z

        picoboot_memory_access raw_access(con);
        model_t model = raw_access.get_model();
        if (model->supports_picoboot_cmd(PC_REBOOT2)) {
+            uint32_t usb_flags = (settings.led >= 0) ? (settings.active_low ? 0x30u : 0x20u) : 0u;


Perhaps this could be

Suggested change

uint32_t usb_flags = (settings.led >= 0) ? (settings.active_low ? 0x30u : 0x20u) : 0u;

uint32_t usb_flags = 0u;

if (settings.led >= 0) {

usb_flags |= BOOTSEL_FLAG_GPIO_PIN_SPECIFIED;

if (settings.active_low)

usb_flags |= BOOTSEL_FLAG_GPIO_PIN_ACTIVE_LOW;

}

to get rid of the magic numbers?

will-v-pi added this to the 2.3.0 milestone May 29, 2026

will-v-pi requested a review from kilograham May 29, 2026 15:19

will-v-pi mentioned this pull request May 29, 2026

RP2350A-A2 USB BOOT activity LED workaround raspberrypi/pico-sdk#2971

Open

Add support for bootsel activity LED

a3c4197

Can use --led and --active-low arguments with picotool commands that reboot the device to bootsel mode (ie `reboot -u` and forced commands), and can also set default LED with DEFAULT_BOOTSEL_LED to always flash that LED even when --led isn't passed

will-v-pi force-pushed the bootsel-led branch from 5a5bd5f to a3c4197 Compare May 29, 2026 15:38

lurch reviewed May 31, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for bootsel activity LED#316

Add support for bootsel activity LED#316
will-v-pi wants to merge 1 commit into
developfrom
bootsel-led

will-v-pi commented May 29, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

lurch May 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	- `USE_PRECOMPILED`: By default the build uses pre-compiles ELF/BIN files for code that is run on the device (enc_bootloader, xip_ram_perms, and picoboot_flash_id). Setting this to `false` re-compiles these files instead.
	- `USE_PRECOMPILED`: By default the build uses pre-compiled ELF/BIN files for code that is run on the device (enc_bootloader, xip_ram_perms, and picoboot_flash_id). Setting this to `false` re-compiles these files instead.


		These can all be set by passing `-DNAME=VALUE` to your `cmake` command (e.g. `-DGENERATE_FIXED_DOCS_WIDTH=1`).

		Note that the behaviour when setting `PICOTOOL_NO_LIBUSB` or `USE_PRECOMPILED` is undefined when using an existing build directory, due to the use of CMake external projects - instead you should create a new build directory to ensure it is in the correct state. No newline at end of file

	Note that the behaviour when setting `PICOTOOL_NO_LIBUSB` or `USE_PRECOMPILED` is undefined when using an existing build directory, due to the use of CMake external projects - instead you should create a new build directory to ensure it is in the correct state.
	Note: when setting `PICOTOOL_NO_LIBUSB` or `USE_PRECOMPILED` you should create a new build directory (rather than using an existing build directory), due to the way `picotool` uses external CMake projects.

	Flash LED on this GPIO to show BOOTSEL activity (ignored by Arm RP2350-A2) - only applicable if this command reboots the device
	Flash LED on this GPIO to show BOOTSEL activity (ignored by RP2350-A2 in Arm mode) - only applicable if this command reboots the device

	The BOOTSEL activity LED is active low (ignored on RP2040 and RP2350-A4)
	The BOOTSEL activity LED is active low (ignored by RP2040 and RP2350-A4)

-            uint32_t usb_flags = (settings.led >= 0) ? (settings.active_low ? 0x30u : 0x20u) : 0u;
+            uint32_t usb_flags = 0u;
+            if (settings.led >= 0) {
+                usb_flags |= BOOTSEL_FLAG_GPIO_PIN_SPECIFIED;
+                if (settings.active_low)
+                    usb_flags |= BOOTSEL_FLAG_GPIO_PIN_ACTIVE_LOW;
+            }

Conversation

will-v-pi commented May 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants