Software-based system reset?

[jonathangjertsen]

I want to be able to sent a reset command over serial to perform a controlled full system reset (both cores, all peripherals etc) from software, to put the device in a known state. I was trying to find something in the SDK or examples to reset the chip, but came up short. Is there such a thing? If not, how could it be implemented? The closest I could find was reset_usb_boot, but I just want to restart the currently running program.

[lurch]

See #197 and raspberrypi/picotool#23 😃

Unfortunately raspberrypi/picotool#23 hasn't been merged yet because when I was testing it I ran into issues with Windows getting its USB drivers confused when the number of interfaces on a device changed, and I've not yet had the time (too busy with other stuff) to dig into it further 🙁 (but it worked fine on Linux and OSX)

(and of course there's also reset-via-SWD if you've got that hooked up)

[jonathangjertsen]

Thanks! Doesn't quite solve my problem since I am using the UART with a serial adapter instead of USB, and I'd prefer not to require picotool

I tried calling watchdog_reboot (0, SRAM_END, 10), but it didn't come back into the same program, it started blinking the LED? (that's not my code, what's up?)

My current workaround is to call reset_usb_boot(0, 0); and have the serial client program re-upload the uf2, which is OK for my case since I plan on distributing the uf2 with the program anyway.

[kilograham]

I tried calling watchdog_reboot (0, SRAM_END, 10), but it didn't come back into the same program, it started blinking the LED? (that's not my code, what's up?)

Passing 0 as first argument is going to go thru bootrom - i.e. try to boot from flash, and if that fails dump into USB bootloader.
If the LED is blinking it is because you have LED blinking program in flash

If you are trying to reboot into a RAM binary then you need to pass something other than 0 for the PC.

[Wren6991]

but it didn't come back into the same program, it started blinking the LED? (that's not my code, what's up?)

This does sound suspiciously like

• Your program is running from SRAM (a PICO_NO_FLASH=1 binary)
• You have a blink program in flash, from when you first tested the board
• You are rebooting the system
• System then boots from flash, as per this flow chart in the datasheet:

If your program is loaded directly into SRAM there is not in general a way of restarting it without a reload, because mutable static initialised data (the .data section) is mutated in-place. You would need to restore the RAM contents as well as just resetting the system.

So you could either:

• Build your program to run from flash (cmake -DPICO_NO_FLASH=0 ..) -- you haven't confirmed whether or why you are running from SRAM
• Use the PICO_COPY_TO_RAM flag so that your program boots from flash, but loads into SRAM before running.

With either of these you can hard-reset the system using the watchdog_reboot (0, SRAM_END, 10) you are currently using, and it should restart/reload the program fine.

[jonathangjertsen]

Thanks for clearing that up @Wren6991. What you described is exactly right - the program was compiled with -DPICO_NO_FLASH=1 to help with overclocking (the program is a bit like the logic analyzer example and needs to read pins as fast as possible). Using PICO_COPY_TO_RAM should solve the issue.

[kilograham]

seems this can be closed?