Should void rp2040.enableDoubleResetBootloader() work on the Pi Pico 2 RP2350?

[Andy2No]

I tried out a couple of the RP2040 Helper Class functions, on both the original Pi Pico RP2040 and the Pi Pico 2 RP2350, referring to the documentation here:
https://github.com/earlephilhower/arduino-pico/blob/master/docs/rp2040.rst

I found rp2040.reboot() works on both (I made it count up until the USB Serial port was opened and reboot after so many seconds if it wasn't opened), but I could only get rp2040.enableDoubleResetBootloader() to work on the Pi Pico RP2040.

Despite the class name, there are no errors from using them on the RP2350, but rp2040.enableDoubleResetBootloader() doesn't seem to work. Is it supposed to?

There's a bit of a knack to getting it to work on the RP2040 - the timing seems to have to be just right - so maybe I'm just consistently doing it wrong, on the RP2350, but it just doesn't seem to want to work, for me.

The documentation confused me a little. It says:

void rp2040.enableDoubleResetBootloader()

Add a call anywhere in the sketch to rp2040.enableDoubleResetBootloader() and the core will check for a double-tap on reset, and if found will start the USB bootloader.

It turns out that means a double tap / double click on an externally fitted reset button, wired between the RUN pin and GND. I wasn't entirely sure what it meant by USB bootloader either but it means mounting as a removable drive so that a .uf2 file can be put on it, like holding down BOOTSEL while plugging in the USB cable (or with the external Reset button held, then released first).

On the Pico 2 RP2350, double tapping a reset button wired up like that just does a reset, as far as I can tell. I had the busy wait for the USB Serial port flash the onboard LED and whatever I tried, it just started flashing again when I let go of the reset button.

Is this just something that can't work on the RP2350?

[earlephilhower]

It's a pretty simple thing that does. Basically it checks a special location for a set of magic words during the C++ constructor stage. If those words match, then reboot immediately into USB mode. If not, then set those magic words and sleep for 350ms and then set those words to 0. If you hit reset during those 350ms the words will be present on next reboot and off you go. If you don't, the words are erased to 0 and the rest of the boot process continues.

With the ARM v7 security stuff, this may not work because it might blank memory as part of the secure boot process (so you couldn't glitch to get things like private keys). I can take a look at it, but don't hold your breath...

[earlephilhower]

Yes, looks like either the CPU or ROM flushes RAM after a reset, so the flag will always be stomped. Simple test here shows after upload the 2nd stack is all 0 (as expected), but after a HW reset the core1 stack is filled completely with pseudo-random data.

uint32_t *m = (uint32_t *)0x20000000 + 50 * 1024 / 4; // Hardcode address unused by this app for test purposes
void setup() {
  delay(5000);
  Serial.printf("PRE : %08lx %08lx %08lx\n", m[0], m[1], m[2]);
  m[0] = 0xabcd1234;
  m[1] = 0x22229999;
  m[2] = 0x12345678;
  Serial.printf("POST: %08lx %08lx %08lx\n\n\n\n", m[0], m[1], m[2]);
  uint32_t *stack = (uint32_t*)0x20080000;
  for (int i = 0; i < 8192 / 4; i++) {
    if (! (i % 8)) {
      Serial.printf("%08lx: ", stack + i);
    }
    Serial.printf(" %08lX", stack[i]);
    if (7 == (i % 8)) Serial.println();
  }
}

void loop() {
}

It also tries hardcoding a flag in unused space in main RAM, which also gets randomized. If the ROM didn't randomize things then the PRE and POST outputs would both be identical after the 1st reset.

Upload and check output, then hit the reset button and you'll see.

I'll update the docs...

[Andy2No]

Fair enough. Thanks. Mostly I was just curious, but it does seem like a useful feature to have for when the BOOTSEL button wears out.

I'm using BOOTSEL a lot for the official Pi Pico 2 in Windows 7 because it seems I can only have either the USB bootloader driver or the serial port one - I have to uninstall/delete one driver to get the other to work. Just one of the joys of using an unsupported OS. Oddly, the Pimoroni Tiny2350 behaves better - I only need to unplug it and plug it back in again after an upload to get the serial port back.

[earlephilhower]

If you're really hard up and don't mind performing extreme unction, maybe there are 3 memory locations in USB DPRAM or even one of the peripherals you can co-opt for this.

I would guess peripherals reset most registers to 0 on HW reset, but if you check the datasheet you might find enough somewhere that are accessible. Something obvious like PIO instruction RAM is write-only and can't be read back out, so that's out.

The USB DPRAM probably won't be (fully) used and possibly you can stuff the magic word there. Hacking with the uint32_t *m = (uint32_t *)0x20000000; line (replacing 20000... with the DPRAM/register address) and trying would not risk anything other than your time...

[Andy2No]

Thanks. I'll look into that. It's probably better if I add an extension to TinyBasicPlus to PEEK and POKE system memory :) That way I only have to go through the nightmarish flashing process a few times until I get that to work, then I can get the full BASIC memory trashing experience at will. At the moment, it's limited to POKEing the relatively safe address space where the listing and variables are kept... and the rest of that 64k region if I don't allocate it all to it.

[earlephilhower]

You could also do it yourself using flash and not RAM. That's not a good permanent solution due to the amount of writes, but in the beginning of your app just implement the logic using files or EEPROM like (untested)

void setup() {
  LittleFS.begin();
  File f = LittleFS.open("reboot", "r");
  if (f) {
    f.close();
    LittleFS.remove("reboot");
    rp2040.rebootToBootloader();
  }
  f = LittleFS.open("reboot", "w");
  f.println("boom");
  f.close();
  delay(2000); // You have 2 seconds to hit reset and reboot to bootloader...
  LittleFS.remove("reboot");
  ... go on your way ...

You could even put in a LED on/off while waiting to ensure you get it right.

[Andy2No]

That's an interesting approach. I'll give it some more thought. Thanks.

[earlephilhower]

raspberrypi/pico-sdk#2043