Bullseye 5.10.145-ti-r55 & VSCODE C Debugger /

I am working on migrating our development environment to Bullseye 5.10. I am up to kernel 5.10.1450-ti-r55.
When I try to use VSCode to run a simple C program, VSCode sends a warning that no debugger can be found and that I can get one from the Microsoft Marketplace. I try to do that but never seem to get a debugger. Also, I still get this message if I choose the menu option to run without debugging.

What C debugger have others had success getting and installing for VSCode on the BeagleBone Black?
Are there any tips for installing and running that I need to know?
Is there some way to tell VSCode not to look for a debugger?

If I need to read or watch something I just send something to a uart or terminal / linux debug port.

I am keen to start using VSCode too. If an integrated debugger works, that would be amazing.

Are you installing VSCode on a Windows or Linux host, or are you installing it on the target?

I am not working with the BBB but with the BBAI64.

I have used QT Creator in the past. It is a nice IDE, not too heavy on resources.

Cross compiling on a development machine and pushing code to the target is usually better than trying to compile on your target, especially with limited resources.

I believe it uses GDB on the target and a GDB server on the host machine for debugging. Can be used for standard C/C++, but you would need to set up your machine for cross compiling. Not always a simple task.

This was all done on a Linux host, however QT creator is also available for Windows.

But quite often it is quicker to do as @foxsquirrel suggests and add some printf statements to your code.

1 Like

We develop entirely on the target and always have. If I could find some really good instructions on how to set up for development on a Windows 10 machine, I’d try that. So far using the target has worked just fine for us.

We do not have terminals or UART setup to use. It’s crazy but when it comes to debugging PRU code we use two methods - send info back to a host program via Remoteproc or flash a set of LEDS that are connected to GPIOs that aren’t used by our system. It’s crude and meets the need most of the time.

The core question I have though is that I can’t get VSCOde to not look for a debugger even when I specifically tell it not to compile with a debugging. There must be some configuration setting in VSCODE that is causing it to want a debugger installed.

We run directly on the BB Black Wireless target. So close…if I could just get VSCode to stop expecting a debugger or get one installed so it will be ok with it. It never even compiles a program.

My problem is that VSCode will not even compile because it wants a debugger installed. So I can’t even get code to output to a terminal, UART, remoteproc or turn leds on/off to run at all.

I have had decent luck getting Visual Studio 2019 to be my development front-end…with some roadblocks that have popped up recently.

Overall, Visual Studio’s cross-platform development scheme involves using g++ and gdb on the target to manage the actual build and debug. Microsoft wanted the target BBB to have the openssh-server, g++, gdb, make, ninja-build, rsync, and zip packages installed. This 5 minute video was helpful in getting past the “hello world” hurdle: Visual Studio Linux Development with C++ (BeagleBone Black) - YouTube

Visual studio, on hitting the run arrow, will download the sources to the BBB, execute a build on the target, collect remote headers for its local cache, and get a remote GDB session running, and act as the front-end.

Now here’s where I’m running into problems: libgpiod isn’t native, and I’m stuck with the linker failing to find even “gpiod_version_string()” . . .
. . .at least with kernel 5.15.73-bone-rt-r31 and running g++ version 10.2.1.

I’ve been forced, as a temporary workaround to back off to an image with g++ 8.3.0 to get it link.

For that, it was a matter of getting the libgpiod-dev package installed and adding to the visual studio settings “-LLIBDIR /usr/lib/arm-linux-gnueabihf/libgpiod.so.2” into the “Additional Options” text box inside Visual Studio’s project settings under the linker->command line category.

I hope this helps.

Thanks…I’ll check this out. I tried using TI’s CCS, but it wants to be on a Linux box, and I didn’t want to go through the extra trouble of bringing up a Linux emulator on my Windows 10 box. Purists might say to get a Linux box w/o Windows, but we have other tools (CAD, etc.) that need Windows.

1 Like

Windows 10 user here as well.

By the way, there ain’t no way you’ll get a complete kernel source tree onto a Windows filesystem. It’s QDOS roots preclude things like the use of “aux” as a file name base (i.e. “aux.c” won’t make it out of the archive file). I’d be tempted on trying out Microsoft’s WSL2 subsystem, but I’ve nearly plugged the undersized drive that IT issued with my current machine.

Not sure what say about that, I don’t use it.

My mental capacity is a finite resource, I just cannot justify the time learning VSCode and staying on top of it when stuff is arcane and loaded with rabbit holes.

I run virtual box hosted on linux with linux clients and Windows 11 will run in virtualbox on a linux host. Also have a high end CAD workstation that is Win 11 and uses virtual box to host linux. Both do very well and with NVMe on the Windows host you cannot tell you are running a VM.

Hopefully this helps with the confusion in this thread…

With Bullseye, since Cloud9 (a built-in IDE) was no longer viable, we switched to a fork of VSCode that can run in the browser (on target)…

Offically it’s called code-server: GitHub - coder/code-server: VS Code in the browser this is pre-insatlled in Bullseye images and is running on port 3000…

Like VSCode, it has a ton of extensions, however since it’s not an “offical” Microsoft build, it doesn’t have the non-free stuff… So most VSCode extensions are missing or not avaiable.

The open registry of extensions for our version is hosted here:

Sadly i haven’t found a great works for all debug extension like the default in Microsoft’s version…


maybe? gdb + Open VSX Registry


I would be satisfied for the moment if when I chose Run Without Debugging VSCode didn’t pop up a window that says

You don’t have an extension for debugging C. Should we find a C extension in the Marketplace?

And the only options are Cancel and Find C Extension.

When I try Find C Extension, I’m getting

Error while fetching extensions. Certificate is not yet valid.

I have no idea how to get one of those debuggers installed on the VSCode on the target BeagleBone Black Wireless. If I’m connected to the Beagle’s wifi, I can ping just fine. But I’m in my browser and trying to get to Open VSC Registry or Github, no dice. I can see the repo when my Windows 10 box is connected to our office wifi and could download it to my Windows 10 machine, but what do I do then?

I’d be good for now if VSCode would just run without having a C debugger installed!

On your target IF you have UFW enabled

$sudo ufw allow 3000

find your IP of the target

$ip route

from your host machine’s web browser
replace the ip with the ip you discovered on your target using ip route.


If you are able to connect it will load. Just tested this on ai-64 that is running apache instead of the factory image provided nginx.

BBBW are out of stock and our BBB is tied up at the present, this assumes the BBBW is configured like the ai-64.