Adding debug support to a non-ARM EABI board type

[KurtE]

A few of us have been playing around with a different board which is not an arm based board, but instead in this case it is a risc-v board.

We have it downloading to the chip through openOCD and started to experiment trying to get debug to work on this board. Debug does work to these chips using a different IDE (MounRiver).

We have tried a few different things in platform.txt, but each time we hit the debug button we end up with the error message: That it can find the GDB executable.
And it is trying to open arm-none-eabi-gdb.exe
which is not the right name for our GDB...

I am guessing it is probably the issue:
[ INFO ] Debug functionality: an update · Issue #87 · arduino/arduino-ide (github.com)

But was wondering if there is now a solution to this. I know some copied the right gdb executable to the one that is called, but, that may not work if the parameters are different.

Thanks
Kurt

[ptillisch]

Hi @KurtE. The name of the GDB executable is generated from a template like this:

{debug.toolchain.path}/{debug.toolchain.prefix}gdb.exe

If it is trying to use an executable named arm-none-eabi-gdb.exe then that means you have something like this in the platform configuration files (likely platform.txt):

debug.toolchain.prefix=arm-none-eabi-

So just adjust the value of that debug.toolchain.prefix property as is appropriate for the toolchain you are using.

[Merlin513]

Hi @ptillisch
I am one of the "us" @KurtE referred to :). That is exactly what we did:

debug.executable={build.path}/{build.project_name}.elf
debug.toolchain=gcc
debug.toolchain.path={compiler.path}
debug.toolchain.prefix=riscv-none-embed-
debug.server=openocd
debug.server.openocd.path={runtime.tools.openocd.path}/bin/openocd
debug.server.openocd.scripts_dir={runtime.tools.openocd.path}/bin/scripts/
debug.server.openocd.script={runtime.tools.openocd.path}/bin/{build.openocdscript}

but we still get the error that @KurtE quoted. If you look at the launch.json, the paths look correct but its not changing the prefix for the gdb:

  "configurations": [
    {
      "cwd": "${workspaceRoot}",
      "name": "Arduino",
      "request": "launch",
      "type": "cortex-debug",
      "executable": "C:\\Users\\Merli\\AppData\\Local\\Temp\\arduino\\sketches\\3BBDA2752DEBFA5A18DF010C94A9B26C/ch32v_eeprom_test.ino.elf",
      "servertype": "openocd",
      "serverpath": "C:\\Users\\Merli\\AppData\\Local\\Arduino15\\packages\\xxxx\\tools\\openocd\\1.0.0/bin/openocd",
      "armToolchainPath": "C:\\Users\\Merli\\AppData\\Local\\Arduino15\\packages\\xxxxx\\tools\\riscv-nuclei-elf-gcc\\8.2.0/bin/",
      "configFiles": [
        "C:\\Users\\Merli\\AppData\\Local\\Arduino15\\packages\\xxxx\\tools\\openocd\\1.0.0/bin/wch-riscv.cfg"
      ]
    }
  ]

[KurtE]

@ptillisch

Hi @KurtE. The name of the GDB executable is generated from a template like this:

{debug.toolchain.path}/{debug.toolchain.prefix}gdb.exe

Thanks @ptillisch - We are making some progress (actually @Merlin513 ) is making the progress. And used some of the ESP32 techniques to copy files

We can now get the debugger to come up, but not get very far.

Thought I would try running it on an Supported Arduino board. Looks like MKR Zero and 33 are supported, but looks like you need a $500 debug adapter (JLink BASE) although I am doing it for the fun of it so could get the EDU mini for only $60... Or maybe the Zero.

Was wondering if some of the other debuggers will work with it, like STM link or WCH Link-E or ?? work with these?

Thanks
Kurt

[ptillisch]

@KurtE

We are making some progress (actually @Merlin513 )

Thanks for the update. If you end up still running into that problem with the debug.toolchain.prefix property, please let me know and I'll investigate.

@KurtE

Was wondering if some of the other debuggers will work with it

I'm using this nice little open source CMSIS-DAP compliant debug probe:

CMSIS-DAP Compliant SWD Debugger by Alex Taradov on Tindie

It works perfectly with the SAMD boards and the Arduino IDE 2.x integrated sketch debugger.

The creator Alex Taradov also suggests a DIY debug probe based on a RPi Pico board in the description of that product listing. I haven't found the time to try that out yet, but I would guess it would work fine with the sketch debugger.

You should be able to use any CMSIS-DAP compliant debug probe. I know some of the Arduino Tooling Team members have personally verified that the Atmel-ICE debugger can be used. That one is more spendy than the Alex Taradov debug probe or the J-Link EDU Mini, but at least is more affordable than the professional J-Link probes and you might happen to have access to one already.

The Segger J-Link EDU Mini will also work fine, but you should be aware that the J-Link debug probes aren't "plug and play" like the CMSIS-DAP compliant debug probes. You will need to install the required tools manually and add a configuration file to the sketches you want to debug. You can learn about that from this tutorial:

Using the Segger J-Link Debugger with the MKR Boards | Arduino Documentation

[Merlin513]

@ptillisch - after looking at serveral github issues I figure out what ESP32 was doing for the ESP32C3. Basically they are using a debug_custom.json that is copied into the sketch directory. Made a simple one for our case:

{
	"name":"Arduino on WCH",
	"toolchainPrefix":"riscv-none-embed",
	"svdFile":"debug.svd",
	"request":"launch"
}

but one one thing that struck me is that the toolchainPrefix they are using is without the trailing dash. However, even if I try it with the trailing dash it still fails - want arm version. Only guess is that changing it with debug.toolchain.prefix has no affect.

[KurtE]

@ptillisch

ou should be able to use any CMSIS-DAP compliant debug probe. I know some of the Arduino Tooling Team members have personally verified that the Atmel-ICE debugger can be used. That one is more spendy than the Alex Taradov debug probe or the J-Link EDU Mini, but at least is more affordable than the professional J-Link probes and you might happen to have access to one already.

Thanks,

I ordered one of the boards you mentioned... Has not shipped yet. I may try the RPI Pico boards. (I have an old Atmel Jtag Ice MK2 not sure how different that is to the Atmel ICE.

Need to read up more on what we need to do to work with CMIS-DAP. Suggestions are always appreciated.

Back to experimenting.

Thanks again

[KurtE]

@ptillisch @Merlin513 - Quick update.

I soldered on wires to SWCLK/SWDIO on an Arduino MKRZero as well as an Adafruit Feather M0.

First attempt was with an WCH-LinkE-R0 adapter, that I switched from Risk-V mode to Arm mode. It shows up as a CMIS-DAP type device, but did not want to talk to the Arduino board.

So I soldered on header pins to an RPI-pico board and they now talk

So now I can experiment with it to see it works and then see what parts in the Risc-v setup does not.

What I found confusing is ehen I looked through the Arduino IDE 2 debug page:
Debugging with the Arduino IDE 2 | Arduino Documentation

It does not mention the words CMIS or DAP anywhere. So I had no idea that there were other devices that you can use to debug.

I wonder if there is some setting like speed or the like that is keeping the WCH Link from working. Will do some more experimenting with it later.

Edit: I wonder if the reason the WCH-LinkE does not work, as it does not support the HID mode?

[KurtE]

Quick note: Probably already an issue, but did not find...

When in the debug mode, and hit a breakpoint or step lines, the documentation shows the current line highlighted, like:

But if I use a different color scheme like your dark one:
About the only thing you notice is the line number has a different color:

Likewise the Dark theme I downloaded which is a Visual Studio Dark:

Visual Studio Light theme is even worse:

Although you can see a minor outline of a box...

[ptillisch]

@KurtE

I use a different color scheme like your dark one:
About the only thing you notice is the line number has a different color:

Thanks for bringing that to our attention @KurtE. I finally found time to submit a formal report to the developers on your behalf:

Poor contrast of current line highlight in "Dark" theme