You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a device is not in BOOTSEL mode but is exposing a reset interface along with STDIO USB, then we can potentially run any command by first resetting the device to BOOTSEL mode, and then performing the original intended command.
We can reset the device into PICOBOOT only mode when doing this to avoid the device ever showing up as a drive
Open question; if we are performing an operation other than "load -x", what should we do after - the device will be left not running. We can either reset it or expose the USB interface at that point (in which case we may as well expose it as soon as reset if we won't be resetting again after the command)
The text was updated successfully, but these errors were encountered:
Perhaps another flag to specify the post-action?
Or maybe trying to collapse a reset; do_command; reset; sequence into a single do_command -f; sequence would be simply better left as separate steps? 🤷 Perhaps the user would be confused by do_command -f; "suddenly" failing if the binary running on the Pico doesn't happen to have the reset vendor interface exposed, whereas just the reset command failing might be more obvious?
What might be even nicer would be a wrapper-script that can do the same actions either via picotool or SWD, but that's probably a discussion for a later day... (and might be something that the community cooks up anyway?)
If a device is not in BOOTSEL mode but is exposing a reset interface along with STDIO USB, then we can potentially run any command by first resetting the device to BOOTSEL mode, and then performing the original intended command.
-f, --force
or whatever from Support "reset" command for non BOOTSEL device with STDIO USB reset interface #13Open question; if we are performing an operation other than "load -x", what should we do after - the device will be left not running. We can either reset it or expose the USB interface at that point (in which case we may as well expose it as soon as reset if we won't be resetting again after the command)
The text was updated successfully, but these errors were encountered: