debugprobe
debugprobe copied to clipboard
raspberrypi
Take advantage of CMSIS-DAP ecosystem
Hi there! 👋🏽 The Pico is quite exciting!
Fyi, there is an open-source ecosystem of debug adapters for Cortex-M devices, based around the CMSIS-DAP protocol. This protocol is well supported by debuggers, including open source tools like pyocd and openocd. And it's very fast in the v2 bulk-pipe form.
Aside from the protocol and reference code, we have the widely used open source DAPLink project that provides debug probe firmware with lots of extra features. Notably, DAPLink is used by micro:bit. We are in the process of switching it to build with gcc by default (ARMmbed/DAPLink#750), as well as support custom SWD implementations—perfect for making use of the Pico's PIO.
We‡ believe working together to enable Pico debug would much more beneficial for the wider community than reimplementing the wheel. We'd be happy to help you take advantage of the existing open source infrastructure for debug, and make available our experience with debug and embedded. Let's talk!
(Btw, I have plans to support the Pico extensively in pyocd. As soon as I get my board(s) on Monday. 😁 It would be nice to work with you on pyocd support.)
‡ I'm speaking for a few of us in Arm Research that work on open source projects like these in our spare time, and sometimes for work.
This was a quick side project for me which is why I used our existing USB stack (TinyUSB) and implemented my own SWD probe. We'd be more than happy for Pico support to be added to DAPLink but don't have plans / time to do it ourselves.
Understood. Although, I believe using DAPLink would result in less maintenance work for you.
On the pyocd side, we are planning to start adding support over the next few weeks (I get my Pico boards tomorrow 😄 ). Single core support should be quick, but multicore will be more difficult due to the, uh, less than ideal structure of the Pico's DAP (pyocd currently doesn't support multi-drop SWD because it's never before been used for multicore devices).
I feel your pain, maybe this is of some help (massaging multi-drop somewhat reasonably into something that didn't quite expect it)
https://github.com/raspberrypi/openocd/commit/dd9dbe8dc9d5fd7d510a102676e266bf857e5f53
Note single core is fine, but you do have to at least select the core (as you probably know)
I've already implemented a TinyUSB-based CMSIS-DAP that runs on rp2040 core0 and debugs core1. Since most debugging tools don't yet support multi-drop (particularly for CMSIS-DAP), including Raspberry's own OpenOCD fork, it automatically does the SWD multi-drop target selection upon a CMSIS-DAP DAP_Connect.
RP2040's built-in support for one core being able to debug the other core was what interested me when reading the datasheet after the announcement. It has the potential to make single-step debugging more available to a general audience at an attractive price point (since it is effectively "built-in").
The source code is here: https://github.com/majbthrd/DapperMime/
As-is, the code uses pico-sdk defaults and compiles to flash and uses scattered addresses throughout SRAM. This is not a desirable configuration.
The preferred configuration is to beat pico-sdk into submission and use the upper SRAM, leaving the lower SRAM for the user app being debugged. Doing this means adding "set(PICO_NO_FLASH 1)" to the project's CMakeList.txt (for whatever reason, to make this work requires doing a "make clean", then touch CMakeList.txt, then do another "make" for the pico-sdk dependencies to use this), and then hacking up ./src/rp2_common/pico_standard_link/memmap_no_flash.ld to use upper SRAM (starting at 0x2003000 works).
@majbthrd that sounds fantastic! It looks as though the cmsis submodule hasn't been checked in at the moment?
Note that the Raspberry Pi OpenOCD fork absolutely supports multi-drop and debugging of both cores
@liamfraser , I probably need to tweak the README.md language for clarity. I was originally going to link directly to CMSIS_5, but then realized when testing the instructions that TinyUSB already had CMSIS_5 as one of its submodules. As a result, if one downloads the TinyUSB submodules, it already has everything.
Note that the Raspberry Pi OpenOCD fork absolutely supports multi-drop and debugging of both cores
@kilograham , I don't believe the fork yet supports multi-drop for CMSIS-DAP (but neither does OpenOCD at the moment). It does for J-Link (as I used that in testing... thanks!).
@liamfraser , I probably need to tweak the README.md language for clarity. I was originally going to link directly to CMSIS_5, but then realized when testing the instructions that TinyUSB already had CMSIS_5 as one of its submodules. As a result, if one downloads the TinyUSB submodules, it already has everything.
@majbthrd Don't rely on TinyUSB submodules, it is only meant to run examples within tinyusb. I would expect other project just clone tinyusb witthout any of its submodules. Since I could move/delete the sub-modules path and lib around.
@majbthrd Don't reply on TinyUSB submodules, it is only meant to run examples within tinyusb. I would expect other project just clone tinyusb witthout any of its submodules. Since I could move/delete the sub-modules path and lib around.
Thanks @hathach , I have revised it to use CMSIS_5 directly.
why not just make this an INTERFACE library the user can link into their binary?
That's an interesting idea! The compiler automatically takes care of de-conflicting memory spaces; core0 would run the debugger and core1 would run the user code. It might be well suited to don't-peek-behind-the-curtain environments like Arduino.
CMSIS conventions have a SystemInit in crt to handle such hooks, but if pico-sdk's wait_for_vector were weakly defined, it could be overloaded to allow such a mechanism.
On the downside, such an approach (mixing two codes at compile time) does force a power cycle and new .uf2 download every time the user wants to revise their code. Keeping them separate allows the debugger to remain resident and the user can dynamically re-download their code at will via CMSIS-DAP.
Yeah, the exact logistics are going to depend on how you are restarting binraries etc... whether you expect to be able to use flash binaries (rewriting the binary you are running is possible but not easy!)...
wait_for_vector is weekly defined, but the core may already be stopped in the bootrom. however you can make a library function that is run at startup which can launch something on core 1.
One the topic of CMSIS-DAP alternatives for RP2040:
If you haven't already seen it, I submitted a PR to support CMSIS-DAP multi-drop with Raspberry Pi's fork of OpenOCD:
https://github.com/raspberrypi/openocd/pull/17
I also now have two different approaches for RP2040 CMSIS-DAP.
One is a drop-in CMSIS-DAP replacement to the existing approaches in Getting Started with Pico.
A second RP2040 substitutes for the Raspberry Pi in Chapter 5, and would be wired in as shown in Appendix A for picoprobe. That source code is:
https://github.com/majbthrd/DapperMime/
The other CMSIS-DAP approach is a RAM only executable that hides out in tiny corners of memory. This needs only one RP2040 where one core acts as the debugger for the other. This is the most appealing to me, but does involve a tradeoff. Since both cores can reset and initialize peripherals, code in the core being debugged can disrupt the core being the debugger. At the moment, pico-sdk does this as part of its initialization procedures, and all Raspberry Pi's example code uses this. The source code for this approach is:
https://github.com/majbthrd/pico-debug/
The Blackmagic debug probe branch https://github.com/UweBonnes/blackmagic/tree/rp supports multidrop and exposes all 3 Pico DPs.
@flit "We are in the process of switching it to build with gcc by default" I was trying to build it earlier this week to install it on a bluepill, I went through a zoo of source code, which I gave up in trying to script. I found another project which I tried to convert from Keil to GCC+Makefiles here: https://github.com/zoobab/STM32F103C8T6_CMSIS-DAP_SWO
@zoobab
@flit "We are in the process of switching it to build with gcc by default" I was trying to build it earlier this week to install it on a bluepill, I went through a zoo of source code, which I gave up in trying to script. I found another project which I tried to convert from Keil to GCC+Makefiles here: https://github.com/zoobab/STM32F103C8T6_CMSIS-DAP_SWO
The experimental_compilers branch has the gcc support. The top-level README.md has instructions on how to build. There are also some wiki pages with current testing status.
The F103 firmware seems stable according to testers, and has been tested on a bluepill.
Pre-built firmware is available through a link on the gcc port discussion.
The Blackmagic debug probe branch https://github.com/UweBonnes/blackmagic/tree/rp supports multidrop and exposes all 3 Pico DPs.
The branch seems to be deleted and not available any more.
The branch was merged in the main tree. Use https://github.com/blackmagic-debug/blackmagic.git!
There is a pull request here.
- https://github.com/raspberrypi/picoprobe/pull/31
