BOOTSEL activity-LED (`REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL` + `GPIO_PIN_SPECIFIED`) does not drive the configured GPIO on RP2350

[anoshyn]

What's wrong

On RP2350 (Pico 2, current develop bootrom), the BOOTSEL activity-LED feature exposed via REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL / rom_reset_usb_boot_extra() does not appear to drive the specified GPIO at all, regardless of arguments.

Repro

Three test firmwares, all run on the same Pico 2 board. Each call to rom_reboot is preceded by three visible blinks on GPIO 25 (driven from user code) to confirm the firmware actually ran. Built against develop at fdd65e6.

Test 1 — sanity check (user code only)

gpio_init(25);
gpio_set_dir(25, GPIO_OUT);
gpio_put(25, 1);
while (1) tight_loop_contents();

Result: LED solid on. Confirms GPIO 25 reaches the LED, polarity is active-high, and the pin can be driven from user code.

Test 2 — SDK-correct args, no ACTIVE_LOW

rom_reboot(
    REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL | REBOOT2_FLAG_NO_RETURN_ON_SUCCESS,
    10,
    /* p0 = flags */ BOOTSEL_FLAG_GPIO_PIN_SPECIFIED,   // 0x20
    /* p1 = gpio  */ 25);

Equivalent to rom_reset_usb_boot_extra(25, 0, false).

Expected: MSD up, activity-LED idle-low (LED off idle, briefly on during MSD activity since this LED is active-high).

Observed: MSD up and serving reads correctly. LED stays off throughout, including during sustained reads driven from the host:

for i in $(seq 1 200); do cat /media/$USER/RP2350/INFO_UF2.TXT > /dev/null; done

Test 3 — SDK-correct args, ACTIVE_LOW set (the diagnostic that nails it)

rom_reboot(
    REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL | REBOOT2_FLAG_NO_RETURN_ON_SUCCESS,
    10,
    /* p0 = flags */ BOOTSEL_FLAG_GPIO_PIN_SPECIFIED | BOOTSEL_FLAG_GPIO_PIN_ACTIVE_LOW,  // 0x30
    /* p1 = gpio  */ 25);

Equivalent to rom_reset_usb_boot_extra(25, 0, true).

Expected: with ACTIVE_LOW, the bootrom holds the pin idle high. On this active-high LED that means LED solid on during BOOTSEL idle, briefly dipping off during activity.

Observed: LED stays off the entire time BOOTSEL is up — no idle drive, no activity blinks.

Why Test 3 is the smoking gun

Test 2 alone could be explained as "bootrom is driving the pin but the reads I'm generating don't register as observable activity pulses on the host." Test 3 rules that out: it requires no activity dependence — the bootrom should be holding the pin statically high for the whole BOOTSEL session — and the pin stays low. So the bootrom isn't driving GPIO 25 at all under any tested combination, even with BOOTSEL_FLAG_GPIO_PIN_SPECIFIED clearly set.

Environment

• SDK: origin/develop at fdd65e6
• Board: Raspberry Pi RP2350 (Pico 2), Board-ID: RP2350, INFO_UF2.TXT reports UF2 Bootloader v1.0
• USB ID in BOOTSEL: 2e8a:000f
• Host: Linux 6.12, libusb-based control-transfer triggers ruled out; tests call rom_reboot directly
• Toolchain: arm-none-eabi-gcc 14.2.1

Related

• Today's testing also resolved the related argument-order question (originally rom_reset_usb_boot_extra appears to pass p0/p1 to rom_reboot in the opposite order from the documented BOOTSEL ABI #2949): the SDK's rom_reset_usb_boot_extra() passes (p0 = flags, p1 = gpio) and the bootrom does interpret them in that order. The doc comments were reversed; PR Fix reversed p0/p1 description in REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL doc #2955 fixes them. So the wrong arg order is not the cause of this bug — my tests above use the correct order and still see no LED drive.
• PR pico_stdio_usb: fix overlap between activity-LED GPIO and active_low bit #2947 fixes a separate wValue bit-overlap in src/rp2_common/pico_stdio_usb/reset_interface.c that confounded my earlier USB-control-transfer-based BOOTSEL tests; today's tests bypass that path entirely.

What I haven't ruled out

• Whether the activity-LED feature works under some specific bootrom revision or specific host-side trigger I haven't tested. If there's a known-good repro pointing at a working configuration on RP2350, I'd appreciate the pointer.
• Whether there's an additional enable bit I'm missing. src/common/boot_picoboot_headers/include/boot/picoboot_constants.h:27-30 only documents DISABLE_MSD_INTERFACE, DISABLE_PICOBOOT_INTERFACE, GPIO_PIN_ACTIVE_LOW, GPIO_PIN_SPECIFIED. The bootrom.h doxygen still uses a stale GPIO_PIN_ENABLED name for the 0x20 flag — same value, just an inconsistent name (orthogonal to this bug).
• Whether GPIO 25 specifically is reserved by the bootrom on RP2350. Worth retrying with a different GPIO if anyone has a Pico 2 with an LED wired to e.g. GPIO 2 they can flash and report.

Happy to send the firmware sources / a self-contained reproducer repo if useful.

[dpgeorge]

When I was playing with rom_reboot() some time ago I found similar issues with discrepancies between the docs and the actual implementation.

I found that to enable the activity LED you also needed to set bit 0x20 in the first argument flags as well as the p0 argument.

Here's the code I found that worked for me on a Pico 2:

rom_reboot(0x22, 100, 0x21, 25)

That actually disables MSD (I just wanted the picoboot USB interface), and I actually sent that command via picoboot (PC_REBOOT2 = 0x0a) but calling it directly from C should be equivalent.

In summary: BOOTSEL_FLAG_GPIO_PIN_SPECIFIED needs to be passed in both flags and p0 for it to work.

[anoshyn]

Confirmed on Pico 2.

Test target: same as the originals in this issue (3-blink visual sanity, then rom_reboot(...)), but with bit 0x20 now set in both positions — the first argument (reboot-flags word) and p0 — exactly as the comment above describes:

rom_reboot(
    REBOOT2_FLAG_REBOOT_TYPE_BOOTSEL | REBOOT2_FLAG_NO_RETURN_ON_SUCCESS | 0x20,
    10,
    /* p0 = flags */ BOOTSEL_FLAG_GPIO_PIN_SPECIFIED,
    /* p1 = gpio  */ 25
);

Result: 3 blinks → MSD enumerates → LED flickers visibly on file reads. Repeated reads of INFO_UF2.TXT produced consistent flicker.

Side note on bit naming: 0x20 in the reboot-flags word is already defined as REBOOT2_FLAG_REBOOT_TO_RISCV in picoboot_constants.h. The bit appears to be overloaded by reboot type — meaning "boot into RISC-V" when REBOOT_TYPE is NORMAL/RAM_IMAGE/FLASH_UPDATE, and "GPIO info follows in p0/p1" when REBOOT_TYPE is BOOTSEL. (Numerically it coincides with BOOTSEL_FLAG_GPIO_PIN_SPECIFIED, which uses the same 0x20 in p0.)

So rom_reset_usb_boot() and rom_reset_usb_boot_extra() in src/rp2_common/pico_bootrom/bootrom.c currently set BOOTSEL_FLAG_GPIO_PIN_SPECIFIED in p0 but never 0x20 in the first arg, which matches the observed "no LED" symptom. Opening a small PR with the fix; happy to defer on whether a new named constant should be introduced for 0x20 in the BOOTSEL context vs. leaving a comment near the literal.

[kilograham]

@dpgeorge what stepping is this? I'm guessing A2 - things seem to work fine for me on A4 without setting 0x20 in both places, and I've yet to find any reason why that should make a difference on A2 ;-)

[kilograham]

ah, i have remembered what the issue is on A2 silicon (it is a side effect of errata RP2350-E3)... so GPIO activity LED worked on RISC-V on QFN60 and Arm/RISC-V on QFN80

So i'm still a bit confused as to what/why 0x20 would help (AFAIK A3/A4 the GPIO activity pin works correctly, though the ACTIVE_LOW got broken on A4!)

[kilograham]

but yes - this AI generated issue is likely to be closed, since the reasoning is flawed (3 is broken because the ACTIVE_LOW doesn't work not because PIN_SPECIFIED doesn't work)

[kilograham]

ah - train of thought just leaving the station - the reason 0x20 works IS because it selects RISC-V, which doesn't have the problem

we should just make this a doc update

[dpgeorge]

@kilograham it was over a year ago when I worked on this topic (I was trying to make a version of picotool in Python...) and I don't remember all the details. I'm very sure it was A2 silicon. I was initially confused by how nothing worked and then discovered the swapped p0/p1 arguments, and I think that led me to just try permutations of the arguments, and eventually found that 0x20 passed in to flags got the activity LED working.

the reason 0x20 works IS because it selects RISC-V, which doesn't have the problem

Ah, right, so in ARM mode the GPIO has the issue, but in RISC-V it does not. That makes sense.

we should just make this a doc update

I agree with that.

[lurch]

Fixed by #2971