debugprobe
debugprobe copied to clipboard
raspberrypi
Document pinout in README
This repo is for the debugprobe software, which can run on a Debug Probe, or a Pico, or an any number of other RP2040-based boards.
Documentation for the Debug Probe hardware (note the different capitalisation) can be found at https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html
In the releases of this repo, there is firmware for the Pico (debugprobe_on_pico.uf2); it could be useful to document what functions are on what pins of the Pi Pico. Now I had to dig through the source code (just to find that the reset pin functionality is not enabled by default, so I have to recompile anyways).
See Appendix A of https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
Hi @redfast00, I think the best way is not to document pinout in README, because you may change the pinout when compiling the binary. I think it's better to add pinout to binary info. You can read pin definition with picotool info debugprobe.uf2 -a. See my pull request #113.
would be nice if a reference to retrieving pinouts through picotool were documented in readme. Either way I'm an pico noob, but everything seems spoonfed (doc & sdk & board-design & flashing) so thx for the huge effort. The only bad thing I can say about pico platform is that some hardware bugs warrant an updated chip design, even if at a higher selling price, as this is just as welcome by the community, and equivalent to, but less effort than, redesigning a totally new model. I'd rather buy a preexisting model with fixed hardware errata rather than a new model with unknown or "won't fix" (or "fixed" by redefining bug as feature or by relativizing the bug as harmless) errata.
I mean, people say new silicon masks cost money, but I don't see how that means buggy rev 0 would cost a few dollars but then fixed revision silicon would have to cost 50 dollars to be economical, but releasing an entirely new model with fixed but newly introduced other errata, would still cost only just a few dollars or be even cheaper.
It is the hardware errata of mcu-venders in general that prompts me to speak.
Also, a readme reference that the picotool is not intended to directly speak with a debugprobe would be nice (for noobs; unless I confused something, but typing picotool info with a debugprobe connected returns
No accessible RP2040/RP2350 devices in BOOTSEL mode were found. even though i can flash & debug through vscode debug menu (i know it uses openocd instead).
would be nice if a reference to retrieving pinouts through picotool were documented in readme.
See https://github.com/raspberrypi/picotool/blob/master/README.md#info and point it at your UF2 file.
Also, a readme reference that the picotool is not intended to directly speak with a debugprobe would be nice (for noobs; unless I confused something, but typing picotool info with a debugprobe connected returns No accessible RP2040/RP2350 devices in BOOTSEL mode were found. even though i can flash & debug through vscode debug menu (i know it uses openocd instead).
If you have both a Pico and a DebugProbe connected to your PC, it's 99.9% likely that you'll want picotool to talk to your Pico rather than your DebugProbe. If both devices were visible to picotool, then you'd need to use picotool's "target selection" options every single time.
But if you do want that option, you might be able to set PICO_STDIO_USB_ENABLE_RESET_VIA_VENDOR_INTERFACE (see chapter 5 of https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf ) and then build your own debugprobe.uf2 (although I've not tried this myself).