Add hardware probe model to README

[jhodapp]

It'd be really helpful to people getting started with Rust and the RPi Nano to list what hardware probe model was used in testing this project and how to connect it.

I've successfully used SWD through an RPi4 to the Nano, but not with probe-run.

[9names]

The readme states you need a CMSIS-DAP probe and a custom fork of probe-run-rp
I'm assuming you got it going using OpenOCD with the RPI4?
I've used a WeAct MiniF4 and following the readme, and it worked fine.

As for listing which hardware supports CMSIS-DAP, how to program it and flash the debugger firmware, how to connect it - well, it quickly ends up becoming over half of the readme!

Here's a brief list I've got going at the moment:

You can use a second Pico as a CMSIS-DAP debug probe by installing the following firmware on it in bootloader mode:
https://github.com/majbthrd/DapperMime/releases/download/20210225/raspberry_pi_pico-DapperMime.uf2

Another popular option is to use a WeAct MiniF4 as described here under The powerful route
https://therealprof.github.io/blog/usb-c-pill-part1/

Another popular option is a st-linkv2 clone or other stm32f103 board and
https://github.com/devanlai/dap42

You can use a commercial probe like these ones from NXP. Note that you still need to load CMSIS-DAP firmware onto these probes - they default to running LPC-Link firmware.
LPC-Link2: https://www.nxp.com/design/microcontrollers-developer-resources/lpc-link2:OM13054
MCU-Link: https://www.nxp.com/part/MCU-LINK#/

Finally, you can use DAPLink firmware with any of it's supported chips. You'll need to use the 'develop' branch to use GCC to build it, find a board with the correct chip, etc.
https://github.com/ARMmbed/DAPLink/tree/develop

[jhodapp]

Thanks very much for the reply. I did utilize a RPi4 with SWD to do some live debugging but wasn't familiar with CMSIS-DAP debuggers at all to say whether one could get any of them out there and have it generally be plug and play.

I also have an st-linkv2 debugger. But what I was hoping for was to not really have to spend any time setting up a hardware debugger since I want to focus on learning and debugging Rust on the RP2040 Pico board.

[9names]

I totally understand, and that is why the examples in rp2040-hal are set up to run without a debugger - so those who do not want to use one do not have to deal with buying or setting anything up.
Can't do much about st-link v2 not working as it doesn't support multidrop SWD, and that is required to debug rp2040.
I do not think there is a simpler solution today for debugging Rust on rp2040 than setting up a second Pico to act as the debugger.

Thanks for the details, and the initial issue for prodding me to make this a bit more documented.
I'm hoping the new readme + probe guide in rp2040-project-template do a better job of explaining how to get everything set up, but they definitely do need more work.