pico_stdio_usb should (optionally) support a mechanism to reboot the RP2040 device #112

New issue

Closed

opened 2021-02-10 15:05:29 -06:00 by kilograham · 3 comments

kilograham commented

2021-02-10 15:05:29 -06:00

(Migrated from github.com)

@MichaelBell has a fork which supports reboot when baud rate is set to 1200.

This is not ideal for picotool, because the OS is understandably not keen on you trying to talk CDC commands directly to a serial device it has claimed, and mapping from VID/PID to serial device is brittle/at-least-needing-of-an-external-library-for-cross-platform-support.

I suggest therefore, that we additionally define an additional interface for controlling the RP2040 (a sort of runtime companion to PICOBOOT but much simpler). picotool already needs a driver on windows anyways, so hopefully this isn't a huge issue for the user (although they may need to do this now for two interfaces?)

We can support both methods by #define in pico_stdio_usb, but we should document the extra interface so MicroPython, CircuitPython etc can support it in their REPL if they want

@MichaelBell has a fork which supports reboot when baud rate is set to 1200. This is not ideal for picotool, because the OS is understandably not keen on you trying to talk CDC commands directly to a serial device it has claimed, and mapping from VID/PID to serial device is brittle/at-least-needing-of-an-external-library-for-cross-platform-support. I suggest therefore, that we additionally define an additional interface for controlling the RP2040 (a sort of runtime companion to PICOBOOT but much simpler). picotool already needs a driver on windows anyways, so hopefully this isn't a huge issue for the user (although they may need to do this now for two interfaces?) We can support both methods by #define in pico_stdio_usb, but we should document the extra interface so MicroPython, CircuitPython etc can support it in their REPL if they want

hathach commented

2021-02-13 03:14:11 -06:00

(Migrated from github.com)

Maybe it is worth looking at dfu runtime, it uses control transfer and doesn’t take any extra endpoint and work with dfu-util commanddfu-util -e

github.com/hathach/tinyusb@09868434cd/examples/device/dfu_runtime/src/main.c (L115)

Maybe it is worth looking at dfu runtime, it uses control transfer and doesn’t take any extra endpoint and work with dfu-util command`dfu-util -e` https://github.com/hathach/tinyusb/blob/09868434cd9f53394350cce682333ada97f796c3/examples/device/dfu_runtime/src/main.c#L115

swetland commented

2021-02-14 03:53:13 -06:00

(Migrated from github.com)

This is probably a whole separate issue, but along the idea of "hands free" development just with picotool and debug over usb, it might be worth defining a default fault handler and protocol for passing minimal fault info (PC, FaultAddr, etc) across a soft reboot (and if sram can survive that, possibly park in picoboot or a postmortem interface where one could pull a ram dump, backtrace, etc)....

kilograham commented

2021-03-04 19:06:42 -06:00

(Migrated from github.com)

This is probably a whole separate issue, but along the idea of "hands free" development just with picotool and debug over usb, it might be worth defining a default fault handler and protocol for passing minimal fault info (PC, FaultAddr, etc) across a soft reboot (and if sram can survive that, possibly park in picoboot or a postmortem interface where one could pull a ram dump, backtrace, etc)....

can you please open this as a separate issue; as the main issue is fixed

> This is probably a whole separate issue, but along the idea of "hands free" development just with picotool and debug over usb, it might be worth defining a default fault handler and protocol for passing minimal fault info (PC, FaultAddr, etc) across a soft reboot (and if sram can survive that, possibly park in picoboot or a postmortem interface where one could pull a ram dump, backtrace, etc).... can you please open this as a separate issue; as the main issue is fixed