Implement reset() and halt() functions

[jannic]

Possible implementation of #564

[jannic]

Unfortunately, I'm yet to find a good way to reset the rp2040 without losing the debug connection.

The current implementation, which just stops core1 an then calls sys_reset does work, but doesn't fully reset the rp2040. Notably, the spinlocks aren't reset.

However, any attempt to also reset the SIO (which hosts the spinlocks) also breaks the debug connection.

I tend to drop the requirement that the debug connection should stay alive, and instead just trigger a full watchdog reset. Any opinions?

[jannic]

For now, I settled on just doing a full reset, even if it breaks the debug connection. I consider a reliable reset more important than the ability to debug through a reset sequence.

[thejpster]

Neotron Pico BIOS uses scratchpad registers to detect a core0 reset and forces a SoC reset with the watchdog. probe-rs gets kicked out, but the workaround I found is to flash it from within the USB bootloader - none of my hardware is configured, and so my crowbar routine is neither triggered nor required.

[jannic]

Neotron Pico BIOS uses scratchpad registers to detect a core0 reset and forces a SoC reset with the watchdog. probe-rs gets kicked out, but the workaround I found is to flash it from within the USB bootloader - none of my hardware is configured, and so my crowbar routine is neither triggered nor required.

That's a nice solution, but I don't think it's suitable for the HAL: The firmware might need the scratchpad registers for some other purpose.

Also, what this PR implements is mainly what you do in watchdog_reboot, just without the 10ms delay. If the firmware author makes sure to use it everywhere instead of calling sys_reset, no boot-time workaround is needed. (Of course, the workaround would still be useful in case the incomplete reset was done by the debug probe.)

[thejpster]

rebase on 674 I guess?