Ken CTO of Canis Automotive Labs

Debugging C on the CANPico

The Raspberry Pi Pico is an excellent embedded platform, noted for its excellent documentation (and also the RP2040 microcontroller, one of the few that is currently not made from unobtainium). But one of the great features of this board is how it gets more and more support over time. And that’s why we used it as the basis for the CANPico.

The CANPico currently has a MicroPython SDK for easily handling CAN frames, but many people have asked about a C SDK for it. So we have been working on it, and the release is imminent. But in the meantime I thought it would be useful to give a short guide on getting a debugger to work for C applications on the Pico (and CANPico).

It’s actually pretty straightforward. The best guide I found to this is in two parts:

  • Part 1 covers setting up Microsoft Visual Studio Code (‘VSCode’) to develop C code for the Pico.
  • Part 2 covers setting up a second Pico as an OpenOCD debugger for the Pico.

There are some issues that might be encountered when following this guide. I’m developing on an Ubuntu 20.04 VM under Parallels running on a Macbook M1. This means the 64-bit Arm version of Ubuntu is being used, and there are some problems I encountered.

The first problem is that the Arm cross-compiler that comes with Ubuntu is quite old, and a new version has to be downloaded as a binary from Arm. This means using the 64-bit Arm Ubuntu download from Arm’s web site. Installing this is a bit tricky because quite a few tools have embedded the pathname /usr/bin/arm-none-eabi-gcc for the compiler. So you need to create a symbolic link for every arm-none-eabi- tool to where the binary Arm compiler is normally installed (the latest version installs to /usr/share/gcc-arm-11.2-2022.02-aarch64-arm-none-eabi/bin/). I did this with:

sudo for i in addr2line ar as c++ c++filt cpp elfedit gcc-11.2.1 gcc-ar gcc-nm gcov gcov-dump gcov-tool gdb-add-index gfortran gprof ld ld.bfd lto-dump nm objdump ranlib readelf strings strip; do sudo ln -s /usr/share/gcc-arm-11.2-2022.02-aarch64-arm-none-eabi/bin/arm-none-eabi-$i /usr/bin/arm-none-eabi-$i; done

The next problem is the debugger. VSCode uses the Gnu debugger GDB as a backend, and the binary file arm-none-eabi-gdb from Arm uses some dynamically linked libraries that aren’t installed by default. You can check the libraries needed, and whether they are there with:

$ ldd /usr/share/gcc-arm-11.2-2022.02-aarch64-arm-none-eabi/bin/arm-none-eabi-gdb (0x0000ffffa93e5000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8afd000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8abf000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8aab000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8551000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8520000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8475000) => /lib/aarch64-linux-gnu/ (0x0000ffffa843e000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8259000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8235000) => /lib/aarch64-linux-gnu/ (0x0000ffffa80c2000)
/lib/ (0x0000ffffa93b5000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8098000) => /lib/aarch64-linux-gnu/ (0x0000ffffa8084000)

I found that the libcurses library needed to be installed:

$ sudo apt-get install libncurses5

And the Python library I had was a different version. The workaround I found was to link to another version of the library:

$ cd /lib/aarch64-Linux-gnu
$ sudo ln -s

Next problem: when trying to run the debugger it won’t talk to the Pico running picoprobe, and in VSCode the console output shows a USB error. This is down to the udev rules that don’t allow access to the Pico over USB. The fix is to use a rules file in the openocd distribution (my OpenOCD repository is cloned from the Raspberry Pi OpenOCD repo to ~github/openocd):

$ cd ~/github/openocd/contrib
$ sudo cp 60-openocd.rules /etc/udev/rules.d
$ sudo udevadm control --reload-rules

Next problem: the recommended Cortex extension in VSCode complains about runToMain being deprecated. To get rid of this error, edit the launch.json and replace the line:

"runToMain": true,


"runToEntryPoint": "main"

Next problem is that setting more than four breakpoints causes GDB to fail with an “Exception has occurred” error. And because breakpoints persist across sessions, it will continue to report an error after a restart. The clue is in the console where it reports:

Error: Can not find free FPB Comparator!
Error: can't add breakpoint: resource not available!

This is an easy bear trap to fall into. Be careful with those breakpoints!

Next problem is the debugging toolbar in VSCode. The debug start is the one in the floating toolbar with green ‘play’ and red ‘stop’ icons. The default debug toolbar entry in VSCode doesn’t work and fails with an error. Another bear trap!

Next problem is getting printf() on the target Pico working. The way it works is that outputs from the UART goes to the picoprobe, which forwards it over USB serial. When you plug in the picoprobe, the device /dev/ttyACM0 should appear (or something else if there are other USB serial devices that grabbed the port). Annoyingly, a lot of the regular terminal tools don’t appear to work nicely. The tool I got working to display the results is minicom. It’s installed with:

$ sudo apt-get install minicom

And run with:

$ minicom -b115200 -o -D /dev/ttyACM0

Quitting minicom is almost as hard as quitting vi: do CTRL-A then x. You do need to specify the baud rate, even though it’s coming over USB serial.

The final problem is that sometimes the errors aren’t just finicky whining from a fragile toolchain, but actually are genuine. I spent a couple of minutes trying to find out why the debugger had stopped working only to discover I’d unplugged the picoprobe!

Finally, here’s a picture of a CANPico board connected to a Pico running the picoprobe firmware. Individual header pins are soldered into the Pico mounted on the CANPico board (for power/ground, UART and SWD). The colours of the wires match the ones in the official guide, and note that RX/TX for the UART are swapped over.

Pico debugger running picoprobe connected to CANPico board

Here I’m running a very simple C test program for the CANPico that just sends a CAN frame every half second and prints to stdout (it runs at a CAN bit rate of 500kbit/sec).

The VSCode debugger looks like this:

VSCode debugging of simple CAN test program

And the minicom terminal window looks like this:

minicom terminal window showing printf outputs from the test program

The binary .uf2 firmware for the test program can be flashed into the CANPico to make a neat little development tool for checking CAN is wired up OK.

comments powered by Disqus