HowTo: VS Code debugging with St-Link JTAG

I got my Daisy Pod this morning after a 6 week USP delay, I live in the UK btw.
I don’t use VisualGDB or Visual Studio 2019 as I don’t like how Visual Studio 2019 handles C++ projects with its insistence of not allowing you to add actual folders to structure your code better.

Using the Pod MultiEffect project, but any STM32H7 project should be ok with the following.

I use Visual Studio Code and I flash and debug via an STM St-Link ver 3 JTAG.

You will need a JTAG 2x10 way mini/micro cable converter to plug into the Daisy Seed.
I got mine from here

Don’t forget I’m in the UK/Europe. You should have distributors nearer to your home.

Note the orientation of the Daisy Seed end of the connector as detailed here

“ If you’re using the ST-Link, connect the IDC cable with the redstripe facing up toward the white stripe on the 2x10 male connector on the top of the Daisy Seed.”
Squint at your Daisy Seed and you should just about see it next to the H7 chip itself.

Below is a debug config/launch.json that fires up OpenOCD and allows breakpoints, single step, watch etc.
Note: I’m on a Windows10 machine at the moment, my Mac is busy doing other things.
I have been developing with STM32 devices for a couple of years now so my setup is stable.
This is what I have/did
Note: I know PlatformIO creates an environment for Daisy, but I haven’t used it as yet, I’m old school

1: Down load the latest ARM cortex Compiler/Linker and installed it to the default folder
C:\program Files (x86)\GNU Arm Embedded Toolchain\9 2020-q2-update

2: Downloaded OpenOCD and installed to the default location
C:\Program Files\OpenOCD10
For I & 2 above, if prompted during install add paths to your evn. If not manually add them i.e. point to the bin folder.

3: Get the stm32H750x.svd required in the launch.json file from here
It’s a big file so you’ll probably have to just copy the ‘raw’ file

I created a file by the same name in the daisy seed folder then pasted into that file
The .svd is just a description file for the STM32 processor required by the debugger.
So we now have three file links that are going to be used in launch.json

Below is the launch.json.
Note my hard coded paths and the VS Code attributes e.g. ${workspaceRoot}
You may/will have to change the paths in your launch.json to point to your installs and to the .elf file your current project is compiling.

    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit:
    "version": "0.2.0",
    "configurations": [       
            "cwd": "${workspaceFolder}",
            "executable": "${workspaceRoot}\\Desktop\\DaisyExamples\\pod\\MultiEffect\\build\\MultiEffect.elf",
            "name": "JTAG DEBUGGING ",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "armToolchainPath": "C:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\9 2020-q2-update\\bin",
            "interface": "swd",
            "svdFile": "${workspaceRoot}\\Desktop\\DaisyExamples\\seed\\stm32H750x.svd",
            "runToMain": true,
            "configFiles": [
            "debuggerArgs": [
            "preRestartCommands": [
                "enable breakpoint",
                "monitor reset"
            "showDevDebugOutput": true,

In the launch.json above you’ll see the following
“configFiles”: [
These are config files for OpenOCD that get installed with OpenOCD.

Now make your project (MultiEffect ) using the Daisy make file as usual.
When compiled/linked successfully In VS Code click on the Debug icon and the drop down should display JTAG DEBUGGING, you can change the name in launch.json to whatever you want.

Click the green run icon , you should see a lot of ‘low level’ message text in the Debug Console of VS Code as OpenOCD starts up.
Your code might halt execution at the init() function, click the blue continue icon in the debug floating menu.
Now, set a breakpoint somewhere in your code that you know will be hit. And, run to that breakpoint.
But it doesn’t hit the break point and you’ll get a message complaining about a missing symbol file !

We need to do one last little thing that is create a symbol file.

In the project e.g MultiEffect there is a project local makefile.
This calls by way of an include the main Daisy Seed make file in libdaisy folder
At about line 208 in this main make file you’ll see

ifeq ($(DEBUG), 1)
CFLAGS += -g -gdwarf-2

If this DEBUG equals 1 set the –g flag on the compiler, this flag basically creates the symbol file.

So where is DEBUG, where can we set it ?
You could set it in the main makefile in the libdaisy folder but that would set debug/symbols for every project you compile.
It’s better to set is locally, project locally.

So back to the local makefile in the folder MultiEffect (in this example) and add the following

#required for the compiler to generate symbols for debugging

So your local makefile looks like

# Project Name
TARGET = MultiEffect

#required for the compiler to generate symbols for debugging

# Sources
CPP_SOURCES = MultiEffect.cpp

# Library Locations
LIBDAISY_DIR = ../../libdaisy
DAISYSP_DIR = ../../DaisySP

# Core location, and generic Makefile.
include $(SYSTEM_FILES_DIR)/Makefile

Save the makefile and run the debug launch again, set a break point and hopefully your code will halt at the break point.
Depending on your VS Code setup you should see a few windows with debug info in them e.g. Call Stack, Registers, Watch.

Any problems, check the install folders, environment paths. The path in the launch.json file.
Watch out for path delimiting slashes etc.

Hope this helps
Stay Safe, and remember “the lunatics have taken over the asylum“


Very nice guide! I will just add that for anyone not having a programmer yet, a more cost-effective solution would be to buy STLink v3 mini - it’s cheaper than programmer mentioned above and doesn’t require using JTAG to MiniJTAG adapter.


@bikerboyroy do you know if this would be possible on mac? Would any of the steps be different? I’ve managed to install the openOCD binary using xPack (, but I’m not sure where to find the latest ARM cortex Compiler/Linker.

Also you mentioned you don’t use Platform IO - what does your VSCode project file directory look like? I’m very new to VSCode, and so far I’ve just created projects using Platform IO, and it automatically generates various directories and .json files etc. I’m not sure what is required starting from scratch!

Thanks for your help! :raised_hands:


I can’t really help with a Mac, I don’t dev on a Mac I use it for my studio, running Ableton and vst’s etc.

But the basics of the launch.json file should still apply.

The toolchain for Daisy dev on a Mac can be installed via the instructions on this link

The compiler/linker might be installed to

OpenOCD might be installed to

You could then try this VSCode extension, updated June 2020
I think this sets up a debug launch.
I’ve not used it but it gets good reviews.
Read the wiki

As far as project structure, I’d stick to the default Daisy ones until you get better acquainted with Daisy and VS Code.
The Daisy project structure by default i.e. the one that is installed from the GitHub , git clone.
That way paths to the includes and libs will be maintained.

In VS Code you might get errors with it not locating includes, red squiggles under the #include
You may have to enter the include paths into the c_cpp_properties.json file of VS Code

I might have ago at installing on to my Mac, but I have limited disk space on it.
If I do , I’ll post a template on here if I’m successful , but it’ll be a few days before I do

Yes, good catch.
I’ve been deving with STM for nearly three years now, always used the ‘bigger’ link probes , forgot about the mini’s

Thanks, I’ll look into that VS Code extension. I’ve already followed the instructions on the wiki for installing the mac toolchain, but couldn’t get OCD to build at the last step, which is why I tried the xPack method.

In terms of the project structure, I wasn’t intending to play around with the Daisy library structure, I just meant which additional files are required by VSCode. Is it just c_cpp_properties.json, extensions.json and launch.json? I know that PlatformIO puts these in a directory called .vscode.

Thanks again!

Yes these 3: c_cpp_properties.json, extensions.json and launch.json
And you might look at using a task.json as well

Thanks for the suggestion antisvin, I’m considering purchasing the STLink v3 mini. But I see the supplied cable has a 14 pin connector on it whereas the Daisy has a 10 pin header.

How do you connect the two?

Yeah, that’s right. There are 2 unused connections on each side, so you should just make sure that their centers match. And there’s mark on Daisy that shows on which side you should place red stripe on programmer cable. You must power Daisy separately, programmer won’t supply power to it.

Wow, thanks for a superfast response! Ordering the V3 mini now…

Thank you for this guide, we got it working as well thanks to you, using an STLinkV2.
Some notes, maybe this helps someone later:

  • We had to install the cortex-debug extension
  • then in Settings (Ctrl+,), under User > Extensions > Cortex Debug edit the Arm Toolchain Patch and Openocd Path to match our install (hit “Edit in settings.json”)

The two lines in settings.json look like this:

"cortex-debug.armToolchainPath": "C:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\9 2020-q2-update\\bin",
"cortex-debug.openocdPath": "C:\\Program Files\\OpenOCD10\\bin\\openocd.exe"
1 Like

I realize now I should mention here that all of the DaisyExamples projects have built-in VS Code support now as well. The script in the same repo can be used to duplicate existing, or create new projects with the the necessary configuration/files for debugging in VS Code.