search

Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
985 stars 238 forks source link

Error: spawn arm-none-eabi-gdb ENOENT #8

Closed quantexlab closed 6 years ago

quantexlab commented 6 years ago

Hallo. Thanks for your plugin. I'm trying to use it.

launch.json { "version": "0.2.0", "configurations": [ { "name": "Debug Microcontroller", "request": "launch", "type": "cortex-debug", "executable": "${workspaceRoot}/_debug/sdw_d.elf", "cwd": "${workspaceRoot}", "servertype": "jlink", "device": "STM32F446RE", } ] }

vscode debug console:

Could not start debugger process, does the program exist in filesystem? Error: spawn arm-none-eabi-gdb ENOENT

Terminal:

Andreys-Mac-Pro:Dev andrey$ arm-none-eabi-gdb GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 7.12.1.20170215-git Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi". Type "show configuration" for configuration details. ---Type to continue, or q to quit--- For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) Quit Andreys-Mac-Pro:Dev andrey$

What am I doing wrong?

Marus commented 6 years ago

Is arm-none-eabi-gdb and other related tools on your system path? That indicates that it couldn’t find the executable.

You should try setting the cortex-debug.armTooochainPath setting to the directory containing the arm-none-eabi executables.

quantexlab commented 6 years ago

Is arm-none-eabi-gdb and other related tools on your system path? That indicates that it couldn’t find the executable.

Yes. Other tools work on your system path.

You should try setting the cortex-debug.armTooochainPath setting to the directory containing the arm-none-eabi executables.

That helped. It works. "cortex-debug.armToolchainPath": "/Users/andrey/opt/gcc-arm-none-eabi-6-2017-q1-update/bin/"

Thank you very much for your help

Marus commented 6 years ago

Strange that it is not finding it on your system path; but at least setting the path is working.

rei-vilo commented 6 years ago

Please note

"cortex-debug.armToolchainPath": "/Users/ReiVilo/Library/Energia15/packages/energia/tools/arm-none-eabi-gcc/4.8.4-20140725/bin/"`

(or the value specific to the board) should be placed in settings.json.

Marus commented 6 years ago

@rei-vilo - the particular value, and if you even need this setting, will depend on your setup.

If you install the official stand alone tool chain it will likely be on your system path - and not need to be set. Tools like platform.io or, in your case Energia, tend to hide the tool chain in their internal folders. In these cases you will need to set it - but the value will depend on what installer the arm tool chain and where it installed it to.

rei-vilo commented 6 years ago

Sure, thanks!

mbristol78 commented 4 years ago

Hello, Can I reopen this thread? I have the same issue and same error, gdb is in the path. Within my several trials I also tried to set it manually in the launch.json, and to put the "armToolchainPath": "/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin/" in the settings. Note that for me, it seems to be "armToolchainPath" and not "cortex-debug.armToolchainPath" when placed in the launch. Note arm-none-eabi-gdb was installed when I installed stmCube, in 2 different locations, however I have tried both. (maybe not a good thing to have them both in the PATH?)

This is my launch.json { "version": "0.2.0", "configurations": [ { "name": "Cortex Debug", "cwd": "${workspaceRoot}", "executable": "/local/home/admin/Documents/mockup_src_makefile/mockup_src_makefile/build/mockup_src_makefile.elf", "request": "launch", "type": "cortex-debug", "servertype": "jlink", "device": "STM32H743ZI", "armToolchainPath": "/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin/" // "armToolchainPath": "/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.7-2018-q2-update.linux64_1.0.0.201904181610/tools/bin/" } ] }

Any help please?

Environment

Thanks

haneefdm commented 4 years ago

"cortex-debug.armToolchainPath" is for settings.json because that is a file used by many plugins.

Also, we expect to find arm-none-eabi-gdb and not plain gdb in that path. Can you run arm-none-eabi-gdb from that path manually? maybe you are missing some libraries like library curses.

https://github.com/Marus/cortex-debug/issues/266#issuecomment-604534019

mbristol78 commented 4 years ago

Thanks for your reply. I am confused when you say arm-none-eabi-gdb and not plain gdb Do you mean to explicitly put arm-none-eabi-gdb in the path? like "cortex-debug.armToolchainPath": "/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin/arm-none-eabi-gdb in the setting.json? Doing such result of an error not finding arm-none-eabi-gdb.

I have removed and my launch is now {"version": "0.2.0", "configurations": [ { "name": "Cortex Debug", "cwd": "${workspaceRoot}", "executable": "/local/home/admin/Documents/pht_mockup_src_makefile/pht_mockup_src_makefile/build/pht_mockup_src_makefile.elf", "request": "launch", "type": "cortex-debug", "servertype": "jlink", "device": "STM32H743ZI" } ] } Yes I can execute arm-none-eabi-gdb directly from the bash

haneefdm commented 4 years ago

The executable name we look for is arm-none-eabi-gdb which is specific to arm tools. If you list that directory, what does it look like. The armToolchainPath should not include the name of the executable. We look for other executables in that directory as well.

ls /opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin
mbristol78 commented 4 years ago

This is the ls admin@BWT-DEMO-01 ~/D/p/pht_mockup_src_makefile> ls /opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin arm-none-eabi-addr2line* arm-none-eabi-cpp* arm-none-eabi-gcc-ar* arm-none-eabi-gcov-tool* arm-none-eabi-ld.bfd* arm-none-eabi-readelf* arm-none-eabi-ar* arm-none-eabi-elfedit* arm-none-eabi-gcc-nm* arm-none-eabi-gdb* arm-none-eabi-nm* arm-none-eabi-size* arm-none-eabi-as* arm-none-eabi-g++* arm-none-eabi-gcc-ranlib* arm-none-eabi-gdb-py* arm-none-eabi-objcopy* arm-none-eabi-strings* arm-none-eabi-c++* arm-none-eabi-gcc* arm-none-eabi-gcov* arm-none-eabi-gprof* arm-none-eabi-objdump* arm-none-eabi-strip* arm-none-eabi-c++filt* arm-none-eabi-gcc-7.3.1* arm-none-eabi-gcov-dump* arm-none-eabi-ld* arm-none-eabi-ranlib*

This right executable is in there. I just dont see where in the launch the arm-none-eabi-gdb is specified. Should there be a "program name" or something like that?

Also I note all the executable are own by root, i am admin on the machine, can it be that?

haneefdm commented 4 years ago

You can see what is going on in the "Debug Console". The exact command-line(s) being used. What do you see in that window? Are there any popup messages?

The arm-none-eabi-gdb is hard-coded and added to the armToolchainPath path you specify.

Btw, when pasting unformatted text/code please use the triple quotes so that the lines stay separate. Very hard to read otherwise. You can use the Preview tab to see how your lines are formatting

haneefdm commented 4 years ago

Did you try to run the executable manually? GDB can't run if you have libraries (like curses) missing? Meaning incomplete ARM gdb installation.

mbristol78 commented 4 years ago

in the debug console i have 

Please check OUTPUT tab (Adapter Output) for output from JLinkGDBServer
Launching server: "JLinkGDBServer" "-if" "swd" "-port" "50000" "-swoport" "50001" "-telnetport" "50002" "-device" "STM32H743ZI"

however in the OUTPUT tab.. there is nothing at all.

The elf file upload successfully in on the nucleo board, If i use stmCubeIde, I can run the debugger successfully too. In vscode I can build and flash, but just not debug, which is what I want..

debug_settings_stmcube

mbristol78 commented 4 years ago

Do you mean debugging the elf from the bash? I can do:

admin@DEMO-01 /o/s/s/p/c/t/bin> ./arm-none-eabi-gdb /local/home/admin/Documents/mockup_src_makefile/mockup_src_makefile/build/mockup_src_makefile.elf
GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /local/home/admin/Documents/mockup_src_makefile/mockup_src_makefile/build/mockup_src_makefile.elf...done.
(gdb) b bwt_itf.c:176
Breakpoint 1 at 0x8002ab4: file Drivers/Firmware/Src/bwt_itf.c, line 176.
(gdb) r
Don't know how to run.  Try "help target".
(gdb)

It seems to load and I can set a breakpoint, I dont know how to run it tho;

`help target ' followed by the protocol name.

List of target subcommands:

target core -- Use a core file as a target
target exec -- Use an executable file as a target
target extended-remote -- Use a remote computer via a serial line
target record-btrace -- Collect control-flow trace and provide the execution history
target record-core -- Log program while executing and replay execution from log
target record-full -- Log program while executing and replay execution from log
target remote -- Use a remote computer via a serial line
target tfile -- Use a trace file as a target
haneefdm commented 4 years ago

Good, your gdb is healthy. Thing is that you may have the wrong servertype.

It appears you are using JLink with VSCode but STLink in the other thing.

mbristol78 commented 4 years ago

it doesnt seem like i have the right option then? am i missing something to install? dbg

haneefdm commented 4 years ago

Did you try "stutil"

mbristol78 commented 4 years ago

yep tried that too.. :-(

haneefdm commented 4 years ago

ENOENT means file does not exist. I have a feeling that your problem is not with arm tool chain. It has to do with the location of gdb-server (jlink/stlink/openocd/etc.)

Did you also set up the STLink path? It is done via "serverpath" in launch.json or"cortex-debug.stutilPath"insettings.json`? Otherwise, it won't know how to launch the gdb server.

mbristol78 commented 4 years ago

I have added the line 

"serverpath": "/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin/arm-none-eabi-gdb"

in my launch. it seems to try it but time out. the output tab now shows 

/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin/arm-none-eabi-gdb: unrecognised option '-if'
Use `/opt/st/stm32cubeide_1.3.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-arm-embedded.7-2018-q2-update.linux64_1.0.0.201904120901/tools/bin/arm-none-eabi-gdb --help' for a complete list of options.

When i run the --help in the bash, i cant find any -if options...

When I run arm-none-eabi-gdb in the bash, it says it reads the file and gets me to the prompt, where i can set a breakpoint in the main.c. However when i want to run it, it says Don't know how to run. Try "help target". How do I run it? to see if I have gdb fully working and stepping in the bash first?

I read a few post over the weekend, I didnt find any answers but lots seems to use openOCD as well as j-link, with a svdfile of the nucleo board. Is that another way to debug or investigate?

haneefdm commented 4 years ago

serverpath is not for gdb at all. It is for a gdb-server which is a layer of SW between gdb and the HW. It is things like openocd, jlink, stutil, pyocd, etc.

serverpath must be set to the executable for stlink gdb server. The executable is generally called st-util You can also use (bit more complicated) OpenOCD for stlink boards. Any gdb-server that supports stlink boards can work.

https://github.com/texane/stlink http://openocd.org/doc-release/README Following was never tested, but is probably used by your stmCube IDE https://www.st.com/en/development-tools/st-link-server.html

haneefdm commented 4 years ago

I used to use the free jlink SW to convert an st-link board to a jlink board via a firmware change. I found this to be the best way. You will have to use Windows temporarily to do the conversion.

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

And then download the JLInk gdbserver for your OS, set serverpath to the JLinkGDBServerCLExe executable.

https://www.segger.com/products/debug-probes/j-link/tools/j-link-gdb-server/about-j-link-gdb-server/

mbristol78 commented 4 years ago

ok thanks I'll try the windows conversion later today and let you know. thank you very much

mbristol78 commented 4 years ago

I keep having errors on windows, it doesnt detect the ST-link, altho it is and the NOD_H743ZI2 mass storage, or it says it is in use (which I cant see where and how) I have installed the usb drivers.. reboot ..

I have a j-link segger plus, would it be easier for debugging with vscode?

haneefdm commented 4 years ago

@mbristol78 I tried my best to help you. I am all out of ideas. If JLink conversion did not work, try the other alternatives.

mbristol78 commented 4 years ago

I know you did, and thanks for that again. I will report here if i get something that works.

mbristol78 commented 4 years ago

I read on some post that because the nucleo-h743ZI already has a J-link connector fitted, the J_link Reflash utility cannot convert ST-LINK V3 to J-Link. The user has to use a J-Link probe and the connector. That would explain why my ST-link V3 is not detected by the J-Link Reflash tool. So I guess my options;

elupus commented 1 year ago

For anybody else ending up here after a wild ghost change. Verify that your "cwd" argument points to an existing directory. If that is non existing, you get ENOENT errors.

haneefdm commented 1 year ago

A check (warning) has been added to report an invalid cwd. Because of other settings, it is still possible that things could work, which is why I did not classify it as an error. You will see a Warning balloon if cwd is invalid.

It will be in the next release

gguixe commented 1 year ago

I'm still having the same problem right now. I have tried most of the proposed solutions and no luck yet. I haven't tried J-link.

launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "cwd": "${workspaceRoot}",
            "executable": "./02_control_module/app/build/model_48V/eds500_eth_model_48V_debug.elf",
            "name": "Debug with ST-Link",
            "request": "launch",
            "type": "cortex-debug",
            "runToEntryPoint": "main",
            "showDevDebugOutput": "none",
            "servertype": "stlink",
            "stlinkPath": "~/st/stm32cubeide_1.10.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.300.202203231527/tools/bin/ST-LINK_gdbserver",
            "stm32cubeprogrammer": "/home/gguixe/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin",
            "device": "STM32H73X",
            "v1": false 
        }
    ]
}

settings.json

{
    "workbench.colorTheme": "Default Dark+",
    "yaml.schemas": {
        "file:///home/gguixe/.vscode/extensions/atlassian.atlascode-2.10.12/resources/schemas/pipelines-schema.json": "bitbucket-pipelines.yml"
    },
    "redhat.telemetry.enabled": false,
    "atlascode.jira.enabled": false,
    "security.workspace.trust.untrustedFiles": "open",
    "cortex-debug.armToolchainPath": "~/st/stm32cubeide_1.10.1/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.linux64_1.0.0.202111181127/tools/bin",
    //"cortex-debug.gdbPath": "~/st/stm32cubeide_1.10.1/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.linux64_1.0.0.202111181127/tools/bin/arm-none-eabi-gdb",
    "cortex-debug.stm32cubeprogrammer": "/home/gguixe/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin", 
    "cortex-debug.stlinkPath": "~/st/stm32cubeide_1.10.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_2.0.300.202203231527/tools/bin/ST-LINK_gdbserver" 
}

And the errors are:

GDB executable "~/st/stm32cubeide_1.10.1/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.linux64_1.0.0.202111181127/tools/bin/arm-none-eabi-gdb" was not found. Please configure "cortex-debug.armToolchainPath" or "cortex-debug.gdbPath" correctly.

But the weird thing is that, as in the previous case, arm-none-eabi-gdb actually exists in the folder, and I can ./arm-none-eabi-gdb without problems, gdb opens and works.

gguixe@LAPRDISWGG01:~/st/stm32cubeide_1.10.1/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.linux64_1.0.0.202111181127/tools/bin$ ./arm-none-eabi-gdb
GNU gdb (GNU Tools for STM32 10.3-2021.10.20211105-1100) 10.2.90.20210621-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)
haneefdm commented 1 year ago

I don't think tilde ~ is valid in a path name. It is only valid in a shell. You can use something like ${userHome}

https://code.visualstudio.com/docs/editor/variables-reference#_predefined-variables

gguixe commented 1 year ago

Aaaand it's fixed. Thank you, you're the best.

jpwolfe9912 commented 1 year ago

Hoping to reopen this again! Running STM-32 for VSC on my Mac. I can build and flash code just fine, debugging is giving me the same error message from the original post. Here is my project specific settings.json file. I can include my user settings file as well. 

{
    "C_Cpp.default.configurationProvider": "ms-vscode.makefile-tools",
    "files.associations": {
        "lcd.h": "c",
        "i2c.h": "c",
        "main.h": "c",
        "dma.h": "c",
        "system_stm32wlxx.h": "c",
        "stm32wlxx.h": "c"
    },
    "cortex-debug.armToolchainPath": "/opt/homebrew/Cellar/arm-none-eabi-gcc/10.3-2021.07/bin",
    "cortex-debug.openocdPath": "/opt/homebrew/bin/openocd"
}

launch.json

{
    "configurations": [
        {
            "showDevDebugOutput": "parsed",
            "cwd": "${workspaceRoot}",
            "executable": "./build/WLE5_Peripherals.elf",
            "name": "Debug STM32",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "preLaunchTask": "Build STM",
            "device": "stm32wle5",
            "configFiles": [
                "openocd.cfg"
            ],
            "svdFile": "{workspaceRoot}/STM32WLE5_CM4.svd"
        },
        {
            "showDevDebugOutput": "parsed",
            "cwd": "${workspaceRoot}",
            "executable": "./build/WLE5_Peripherals.elf",
            "name": "Attach STM32",
            "request": "attach",
            "type": "cortex-debug",
            "servertype": "openocd",
            "preLaunchTask": "Build STM",
            "device": "stm32wle5",
            "configFiles": [
                "openocd.cfg"
            ]
        }
    ]
}

tasks.json

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build STM",
            "type": "process",
            "command": "${command:stm32-for-vscode.build}",
            "options": {
                "cwd": "${workspaceRoot}"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$gcc"
            ]
        },
        {
            "label": "Build Clean STM",
            "type": "process",
            "command": "${command:stm32-for-vscode.cleanBuild}",
            "options": {
                "cwd": "${workspaceRoot}"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$gcc"
            ]
        },
        {
            "label": "Flash STM",
            "type": "process",
            "command": "${command:stm32-for-vscode.flash}",
            "options": {
                "cwd": "${workspaceRoot}"
            },
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": [
                "$gcc"
            ]
        }
    ]
}

I can find arm-none-eabi-gcc and arm-none-eabi-gdb in zsh. Any idea what's going on?

haneefdm commented 1 year ago

It would help to see what is in the Debug Console. There can be many things all causing the same error message.

I would not trust openocd that comes via homebrew. Generally far out of date and does not match the official releases made by silicon vendors. Use the one that is shipped by ST as part of their IDE.

jpwolfe9912 commented 1 year ago

Just got it working! I had my debugger path set in my global settings, but not in my project settings. Thank you!

Herant commented 1 year ago

I realise that this thread may be a bit dated, but if, like me, you embarked on the mission to determine whether you could replicate your previous Linux setup on an M2 Mac, here's what I've discovered. Some time ago, I initiated two Makefile projects on Ubuntu. However, upon obtaining an MBP M2, I became eager to migrate my projects. The motivation behind this move was the significantly superior hardware of my Mac, where the '-j12' option outperformed the '-j4' on my Linux machine among other things.

I started by installing everything according to this guide to set up my Mac, with a particular focus on programming my STM32 devices using st-flash from the terminal and debugging them with a GDB server via STLink. Given that I work with multiple STM32 (Nucleo boards), this approach offered the best of both worlds: the ability to program based on STLink ID and the convenience of having Live Watch in the debugger. It appeared that both STUtil and OpenOCD could only provide one of these features, or at least that's what my understanding led me to believe.

After cloning my projects, building and flashing worked right away. However, the debugging did not, which is what led me to this thread. I'm using VSCode as my code editor, so i cloned the 'launch.json' and 'settings.json' files with the same configurations I had on my Linux environment. This meant that I had to adjust file paths for it to work properly. But, it still didn't work, and I kept encountering the error mentioned in this thread's title.

After searching around for a bit, I discovered that the ST-Link debug server (or something like that) was exclusively available within STM32CubeIDE. Although I was initially wanting to avoid installing it, as STM32CubeMX provided everything I needed, I eventually did. In summary, after downloading and installing STM32CubeIDE, creating a test project, and verifying that the ST-Link debugger was operational within it, the debugger suddenly started working seamlessly in VSCode as well.

settings.json

{
  "cortex-debug.stutilPath": "/opt/homebrew/bin/st-util",
  "cortex-debug.gdbPath": "/opt/homebrew/bin/arm-none-eabi-gdb",
  "cortex-debug.armToolchainPath": "/opt/homebrew/bin",
  "cortex-debug.openocdPath": "/opt/homebrew/bin/openocd"
}

launch.json

{
  "version": "0.2.0",
  "projectName": "project_a",
  "configurations": [
    {
      "cwd": "${workspaceFolder}",
      "executable": "${workspaceRoot}/build/project_a.elf",
      "name": "Debug with ST-Link",
      "request": "launch",
      "type": "cortex-debug",
      "runToEntryPoint": "main",
      "showDevDebugOutput": "none",
      "servertype": "stlink",
      "interface": "swd",
      "serialNumber": "066CFF574885524867182747",
      "liveWatch": {
        "enabled": true,
        "samplesPerSecond": 4
      },
      "preLaunchCommands": ["make stflash -j12"],
      "svdFile": "${workspaceRoot}/STM32F303.svd"
    }
  ]
}

Makefile

# *** EOF ***
stflash: $(BUILD_DIR)/$(TARGET).bin
    st-flash --reset --serial 066CFF574885524867182747 write $< 0x08000000
JPHutchins commented 1 year ago

Hi Everyone,

Thanks for the helpful troubleshooting. Here to share a working config (Zephyr) where I need to specify the "serverpath" for the pyocd, but specifically not call it pyocd-gdbserver.

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "mcuboot",
            "type": "cortex-debug",
            "request": "launch",
            "servertype":"pyocd",
            "executable": "${workspaceRoot}/bootloader/build/mcuboot/zephyr/zephyr.elf",
            "device": "stm32l552",
            "svdFile": "${workspaceFolder}/.vscode/stm32l552.svd",
            "runToEntryPoint": "main",
            "toolchainPrefix": "arm-zephyr-eabi",
            "armToolchainPath": "<YOUR LOCATION>/zephyr-sdk-0.16.0/arm-zephyr-eabi/bin",
            "serverpath": "<YOUR LOCATION - maybe not in venv, did you install globally?>/.venv/bin/pyocd",
            "showDevDebugOutput": "raw"
        },
    ]
}

Cheers, J.P.