Add program ('prg') command

[carterturn]

This PR adds a program command to reboot the Pi Pico into programming mode without requiring physical access.

[dihm]

I like the idea, but can't get it to work for me. Whenever I issue prg it just locks up and I have to manually reset to get any operation at all. I'm running Windows 10 for this.

I tried following a crumb of advice that indicates the reset_usb_boot function needs another compile time config to function if stdlib_usb isn't used. It worked for me once, but now I can't get it to work either.

[philipstarkey]

Might be relevant? raspberrypi/pico-bootrom-rp2040#3

[dihm]

I've looked in to this a little more. I don't think the XOSC is the issue, as that is running for us (at least in internal clocking mode, evidenced by the measure frequencies working correctly (measurement is done relative to XOSC according to docs)). I tried calling xosc_init just in case to no avail.

I also discovered that the link I shared is out of date, and the compile time setting is now called PICO_ENTER_USB_BOOT_ON_EXIT. I've tried a few options here. But apparently this works by just calling reset_usb_boot if the main program exits. So it just hangs too.

I did see some comments that the command could fail if it was doing something on the USB when executed, so I added a 500ms delay before calling just to ensure nothing was happening. No luck.

I've also confirmed the function at least partially runs by enabling the status LED via the usb_activity_gpio_pin_mask input for the internal LED on pin 25. When enabled, the LED turns on again, but never goes low due to the lock up.

Finally, in checking clocks, I noticed the peri clock gets knocked down to 48MHz (from 125 MHz default) if the system clock is changed by software. Tried changing the system clock to 48MHz to match, but also doesn't work.

The only thing I haven't tried yet is that there is some references to the USB interface needing to be reset independently of the pico (possibly by the OS) for the reboot to complete. I haven't been able to track this down though, mostly because it seems like this just works for most people. I suspect either our custom serial interface or some clock shenanigans are causing issues.

[dihm]

I've confirmed this works for me once #15 is merged. Going to merge this as ready to go.