Take advantage of CMSIS-DAP ecosystem about debugprobe

[majbthrd]

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).

[flit]

@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.

[majbthrd]

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:

raspberrypi/openocd#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/

[UweBonnes]

The Blackmagic debug probe branch https://github.com/UweBonnes/blackmagic/tree/rp supports multidrop and exposes all 3 Pico DPs.

[majbthrd]

@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.

[UweBonnes]

The branch was merged in the main tree. Use https://github.com/blackmagic-debug/blackmagic.git!

[mcuee]

There is a pull request here.

• #31

[liamfraser]

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.

[flit]

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).

[kilograham]

I feel your pain, maybe this is of some help (massaging multi-drop somewhat reasonably into something that didn't quite expect it)

raspberrypi/openocd@dd9dbe8

Note single core is fine, but you do have to at least select the core (as you probably know)

[flit]

Thanks for the pointer. 👍🏽

[liamfraser]

@majbthrd that sounds fantastic! It looks as though the cmsis submodule hasn't been checked in at the moment?

[kilograham]

Note that the Raspberry Pi OpenOCD fork absolutely supports multi-drop and debugging of both cores

[majbthrd]

@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]

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!).

[hathach]

@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.

[kilograham]

why not just make this an INTERFACE library the user can link into their binary?

[majbthrd]

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.

[kilograham]

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.

[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

[mcuee]

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.

[P33M]

Fixed in #31