Debugging a Raspberry Pi 4 Automotive Grade Linux with Visual Studio Code

TL,DR: AGL Rocks hard. Install VSCode and C/C++ extensions pack, grab a debug enabled AGL SDK, get a copy of a template project I brewed, follow instructions on the README.md: build, deploy, debug and profit.

Debugging capabilities is a crucial part of the development process. Most debugging in Linux systems happens using either gdb or lldb. In this article, I will introduce you to the process I use to remote debug an Embedded Linux application, using a few key tools:

• Microsoft’s Visual Studio Code (VSCode);
• VSCode’s extensions pack for C/C++;
• Automotive Grade Linux and (AGL) Software Development Kit (SDK);
• sshpass : required for inlined password passing — mind your security!;
• Raspberry Pi 4.

You will get a step-by-step process on how to set up Microsoft’s Visual Studio Code to achieve remote debugging — made somewhat easy -, using a template project I brewed and provide here.

Forward acknowledgment: Cross-compiling and remote debugging, on their own, are not trivial tasks to new-comers, so, if anything doesn’t make sense to you, please, drop me a note and/or read through on other sources on cross-compilation.

1. Getting the Goodies

In this step, we will establish the basic setup required to get started. I will not go in too deep, but, here are a few general pointers on where to get what.

• VSCode on Ubuntu: sudo snap install --classic code
• VSCode’s extensions pack for C/C++:

• Automotive Grade Linux (AGL) and Software Development Kit (SDK): please refer to previous post#1 and post#2.
• sshpass: sudo apt instal sshpass
• Yours truly’s Template Project:
  git clone https://github.com/pauloasherring/template-vscode-agl-crossgdb

That should be about it. Moving on.

2. Using the Goodies

Starting the IDE

As I mentioned in previous posts, using AGL’s SDK requires you to source an environment file, exporting all sort of environment variables to let CMake et al. reach your SDK. In order to automate this, you can either source it from a terminal and then run code . to launch a VSCode instance with all that variables.

However, a much more convenient way to get it done is to run configAndCode.sh provided with the template project. So, go ahead and launch it, from the folder you just cloned on step 1 (you may get prompted by CMake's extension to choose from a compiler list. If you are unsure on what to choose, please refer to post#2, where this is discussed in more details).

Configuring to Your Target

In order to use gdb, a few things must be defined, namely: what to debug; where to deploy it to; and how to deploy it, i.e., what credentials to use. The configuration is done on .vscode/settings.json. From VSCode, navigate to it and enter the required input:

• Your target’s IP (targetIP);
• Your target’s UserName (targetUser);
• Your target’s Username’s password (targetPassword);
• Your target’s destination folder, for remote deployment (targetDestFolder);
• Your binary’s file name (targetAppName);
• Your binary’s path (targetInFolder).

These configurations are used in tasks.json to drive the deployment process that happens prior to starting the debugging. Make sure you get these right: you should be able to scp and ssh using the configuration you entered. If you can't do that, you won't be able to debug also, because these are the used mechanisms for driving the debug session.

Building and Debugging

In the building department, the template project offers three tasks, triggerable by CTRL + SHIFT + B:

• CMake Build: runs CMake configure, build, and runs the generated build system;
• CMake Clean: deletes all built files, but keeps caches and others;
• Delete build folder: permanently deletes the build folder, for a harsher reset;
• Extra: Kill remote gdbserver: this is provided as a convenient way to kill stalled gdbservers instances running on the target.

For debugging, CTRL + SHIFT + B and select CMake Build. If you didn't change the CMake file, a binary should have been generated and available at ./build/SampleApp.

After that, press F5 to start debugging. This should take a few seconds to start.

The whole process is depicted below:

Looking Under the Hood

The building process is pretty much a traditional one, the only real difference is sourcing AGL’s SDK config file prior to launching any CMake instance: this allows CMake to correctly identify everything it needs to make a successful cross-compilation. On the present approach, the sourcing needs to be done prior to starting VSCode: CMake will inherit its environment variables.

As for debugging, it takes some more effort. There are a few interesting links, with either a) general ideas; b) targeting other hardware and toolchains; c) targeting other approaches, such as gdb -tui or eclipse. A few of these are: [1], [2], [3], [4].

To briefly describe what happens, the steps involved are:

1. Copy the binary to the target — done here with scp, a copy over ssh tool;
2. Make the binary executable — done here with chmod +x binaryName over an ssh session;
3. Start the gdbserver on the target — done here with gdbserver :3000 binaryName over an ssh session;
4. Connect to the running gdbserver session using the SDK provided gdb binary — done here by VSCode itself.
5. Once connected, use the

To achieve that, I devised a few long one-liner commands, used on tasks.json to achieve that.

3. Conclusion

Microsoft’s Visual Studio Code is an incredible free IDE, chosen by many as the go-to solution. It obviously came a long way, with continuous improvements along the time.

Right now, for embedded developers, such as you and I, it is still somewhat lacking, being a commonplace using the IDE for development and other tools for building and debugging.

In this article, I presented a self brewed VSCode template project, for enabling the development, building and debugging, of embedded Linux targets. Although I do focus on Automotive Grade Linux, the presented approach can be easily adapted to any Yocto-based project.

I hope it helps you :)

If so, please let me know. Also, feedbacks will be much appreciated, for improving my yet blooming blogging skills.

This was originally posted here: The upper Nibble .