VSCode can't use GDB for remote debugging on MAX32620FTHR

I finally succeeded in using VSCode to build an application to run on an MAX32620FTHR target – with substantial help from contributors (such as @JohnnyK JohnnyK and @MultipleMonomials MultipleMonomials) to this forum topic. However, I’m still stumped regarding running GDB to do remote debugging on the target. I was able to run a remote debugger from the MBed Studio, but I have not been able to do that with VSCode. I’m hoping that I’m just missing some basic VSCode settings or environment variables.

I have been told by other contributors to this forum that it is possible to run remote debugging from VSCode, but I saw from the posts that the examples were using Windows as the development platform.

I am using
MacOS Monterey 12.6
GCC 10.3.1 arm-none-eabi
MacBook USB–>MAX32625PICO–>MAX32620FTHR for load of firmware

In my top-level CMakeLists.txt, I have these references to PYOCD:

#enable firmware upload and remote debugging
set(PYOCD_UPLOAD_ENABLED TRUE)
set(PYOCD_TARGET_NAME max32620)

My launch.json (I checked all of the paths; they are all valid):

{
    "configurations": [
	{
	    "type": "cortex-debug",
	    "name": "Connect to GDB Example MAX32620FTHR Debug",
	    "executable": "/Users/howardharkness/arm-workspace/build/Example.elf",
	    "cwd": "${workspaceRoot}",
	    "gdbPath": "/opt/homebrew/bin/arm-none-eabi-gdb",
		"objdumpPath": "/opt/homebrew/bin/arm-none-eabi-objdump",
		"servertype": "external",
		"gdbTarget": "localhost:23331",
		"request": "attach"
	},
    ]
}

My c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Mac",
            "includePath": [
                "${workspaceFolder}",
                "${workspaceFolder}/mbed-os/**"
            ],
            "defines": [],
            "macFrameworkPath": [],
            "compilerPath": "/opt/homebrew/bin/arm-none-eabi-gcc",
            "cStandard": "gnu17",
            "cppStandard": "gnu++17",
            "intelliSenseMode": "${default}",
            "configurationProvider": "ms-vscode.cmake-tools"
        }
    ],
    "version": 4
}

When I try to run the debugger, I get an error telling me that GDB can’t be found, citing a directory (/opt/homebrew/bin/libd) that is not in my system, and I can’t find any reference to “libd” anywhere in my project. So, I conclude that I’m missing some setup or configuration issue. Alternatively, I’m using an incorrect way to try to run it.

I have also been unable to figure out how to use printf() as a poor-man’s debugger.

If you run ninja gdbserver in the bud dir, does that work OK?

By “bud” I assume you mean “build”. I tried running just

ninja gdbserver

– and it returned an error saying that it expected an argument. Looks like I still have some background reading to do.

I’m guessing that gdbserver is a background daemon that needs to be running in order to use pyOCD for debugging. Any pointers to documentation or help files would be appreciated.

howardharkness@FT-Macbook-Pro build % ninja gdbserver
[0/1] Starting pyOCD GDB server
usage: __main__.py gdbserver [-h] [-v] [-q] [-L LOGGERS=LEVEL] [--color [{always,auto,never}]] [-j PATH] [--config PATH] [--no-config] [--script PATH] [-O OPTION=VALUE]
                             [-da DAPARG [DAPARG ...]] [--pack PATH] [-u UNIQUE_ID] [-t TARGET] [-f FREQUENCY] [-W] [-M MODE] [-p PORT] [-T PORT] [-R PORT] [-r]
                             [--allow-remote] [--persist] [--core CORE_LIST] [--elf PATH] [-e {auto,chip,sector}] [--trust-crc] [-C VECTOR_CATCH] [-S]
                             [--step-into-interrupts] [-c CMD [CMD ...]]
__main__.py gdbserver: error: argument -f/--frequency: expected one argument
FAILED: mbed-os/CMakeFiles/gdbserver /Users/howardharkness/arm-workspace/build/mbed-os/CMakeFiles/gdbserver
cd /Users/howardharkness/arm-workspace/build/mbed-os && /opt/homebrew/Frameworks/Python.framework/Versions/3.10/bin/python3.10 -m pyocd gdbserver -v --no-wait -t max32620 -f -p 23331 --persist --semihosting
ninja: build stopped: subcommand failed.

I’ve tried to debug my F746 and got also problems with the external gdbserver. With servertype=jlink in my case it worked. Maybe you can try also to change the servertype in launch.json to pyocd.
Why was it choosen to start over ninja?

@MultipleMonomials – Did you mean:

pyocd gdbserver

?
When I ran that, I got something that looks more promising:

howardharkness@FT-Macbook-Pro build % pyocd gdbserver
0000486 I Target type is max32620 [board]
0000529 I DP IDR = 0x2ba01477 (v1 rev2) [dap]
0000542 I AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2) [ap]
0000567 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=43b:Arm part=4c4) [rom_table]
0000577 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0000581 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0000586 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0000592 I CPU core #0 is Cortex-M4 r0p1 [cortex_m]
0000597 I FPU present: FPv4-SP-D16-M [cortex_m]
0000602 I 4 hardware watchpoints [dwt]
0000607 I 6 hardware breakpoints, 4 literal comparators [fpb]
0000623 I Semihost server started on port 4444 (core 0) [server]
0000785 I GDB server started on port 3333 (core 0) [gdbserver]

However, I still can’t connect to a remote debugger.

It was working for me Project Setup: VS Code - DEBUG · mbed-ce/mbed-os Wiki (github.com)

BR, Jan

this starts the gdbserver with wrong (default) arguments, the gdbserver port does not match.
open a new Terminal window in VSC,
cd build
ninja gdbserver

That should start the server correctly

Oh right, you’ll also need

set(PYOCD_CLOCK_SPEED 4000k)

in your cmake code.

I’m still missing something. Perhaps I missed a setup step(?).

howardharkness@FT-Macbook-Pro build % pwd
/Users/howardharkness/arm-workspace/build
howardharkness@FT-Macbook-Pro build % ninja gdbserver
[0/1] Starting pyOCD GDB server
usage: __main__.py gdbserver [-h] [-v] [-q] [-L LOGGERS=LEVEL] [--color [{always,auto,never}]] [-j PATH] [--config PATH] [--no-config] [--script PATH] [-O OPTION=VALUE] [-da DAPARG [DAPARG ...]]
                             [--pack PATH] [-u UNIQUE_ID] [-t TARGET] [-f FREQUENCY] [-W] [-M MODE] [-p PORT] [-T PORT] [-R PORT] [-r] [--allow-remote] [--persist] [--core CORE_LIST] [--elf PATH]
                             [-e {auto,chip,sector}] [--trust-crc] [-C VECTOR_CATCH] [-S] [--step-into-interrupts] [-c CMD [CMD ...]]
__main__.py gdbserver: error: argument -f/--frequency: expected one argument
FAILED: mbed-os/CMakeFiles/gdbserver /Users/howardharkness/arm-workspace/build/mbed-os/CMakeFiles/gdbserver 
cd /Users/howardharkness/arm-workspace/build/mbed-os && /opt/homebrew/Frameworks/Python.framework/Versions/3.10/bin/python3.10 -m pyocd gdbserver -v --no-wait -t max32620 -f -p 23331 --persist --semihosting
ninja: build stopped: subcommand failed.
howardharkness@FT-Macbook-Pro build %

Ok, that made a difference, although I have no idea why…

howardharkness@FT-Macbook-Pro build % ninja gdbserver
[0/1] Starting pyOCD GDB server
0000283 D Project directory: /Users/howardharkness/arm-workspace/build/mbed-os [session]
0000283 D Project directory: /Users/howardharkness/arm-workspace/build/mbed-os [session]
0000288 D CMSIS-DAP v1 probe 04180000b0cf080000000000000000000000000097969904: protocol version 1.0.0 [dap_access_cmsis_dap]
0000292 D closing interface [hidapi_backend]
0000294 I Target type is max32620 [board]
0000297 D Running task load_svd [sequencer]
0000298 D Running task pre_connect [sequencer]
0000298 D Running task dp_init [sequencer]
0000298 D Running task lock_probe [sequencer]
0000298 D Running task get_probe_capabilities [sequencer]
0000298 D Running task connect [sequencer]
0000324 D Default wire protocol selected; using SWD [dap]
0000326 D Sending deprecated SWJ sequence to select SWD [swj]
0000334 I DP IDR = 0x2ba01477 (v1 rev2) [dap]
0000334 D Running task clear_sticky_err [sequencer]
0000334 D Running task power_up_debug [sequencer]
0000337 D Running task check_version [sequencer]
0000337 D Running task unlock_probe [sequencer]
0000337 D Running task create_discoverer [sequencer]
0000337 D Running task discovery [sequencer]
0000337 D Running task find_aps [sequencer]
0000345 D Running task create_aps [sequencer]
0000345 D Running task create_ap.0 [sequencer]
0000347 I AHB-AP#0 IDR = 0x24770011 (AHB-AP var1 rev2) [ap]
0000351 D AHB-AP#0 default HPROT=3 HNONSEC=0 [ap]
0000353 D AHB-AP#0 implemented HPROT=3 HNONSEC=0 [ap]
0000355 D Running task find_components [sequencer]
0000355 D Running task init_ap.0 [sequencer]
0000364 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=43b:Arm part=4c4) [rom_table]
0000370 I [0]<e000e000:SCS v7-M class=14 designer=43b:Arm part=00c> [rom_table]
0000373 I [1]<e0001000:DWT v7-M class=14 designer=43b:Arm part=002> [rom_table]
0000376 I [2]<e0002000:FPB v7-M class=14 designer=43b:Arm part=003> [rom_table]
0000376 D [3]<fff01002 not present> [rom_table]
0000376 D [4]<fff41002 not present> [rom_table]
0000376 D [5]<fff42002 not present> [rom_table]
0000376 D Running task create_cores [sequencer]
0000376 D Creating SCS component [discovery]
0000376 D selected core #0 [soc_target]
0000381 I CPU core #0 is Cortex-M4 r0p1 [cortex_m]
0000385 I FPU present: FPv4-SP-D16-M [cortex_m]
0000385 D Running task create_components [sequencer]
0000385 D Creating DWT component [discovery]
0000390 I 4 hardware watchpoints [dwt]
0000390 D Creating FPB component [discovery]
0000393 I 6 hardware breakpoints, 4 literal comparators [fpb]
0000393 D fpb has been disabled [fpb]
0000394 D Running task check_for_cores [sequencer]
0000394 D Running task halt_on_connect [sequencer]
0000394 D halting core 0 [cortex_m]
0000397 D Running task post_connect [sequencer]
0000397 D Running task post_connect_hook [sequencer]
0000397 D Running task create_flash [sequencer]
0000397 D Running task notify [sequencer]
0000400 D Setting vector catch to 0x00000001 [cortex_m]
0000405 I Semihost server started on port 4444 (core 0) [server]
0000467 I GDB server started on port 23331 (core 0) [gdbserver]

I’m still unable to run a remote debug:
Screen Shot 2022-10-19 at 2.54.59 PM

Since the debugger appears to be expecting the existence of a directory that is not present, I conclude that I missed a step somewhere that was supposed to create it.

The reason it worked is, that’s one of the required parameters you have to set for pyocd. See the pyocd section in the docs here: Upload Methods · mbed-ce/mbed-os Wiki · GitHub
It must have been substituting in that variable into the command line, and then getting a command line syntax error because it was empty. Maybe we should set up a better error message for this case in the future…

1 Like

Regarding the GDB error, are you sure that you are debugging the correct launch configuration? It sorta looks liie VS Code is trying to run the system GDB, not the ARM one. Can we get a screenshot of what your debug configuations panel looks like?

I’m not sure what you are referring to by “debug configurations panel”. But it is certainly possible that I have the wrong setting somewhere for the debugger.

My settings.json:

{
    "workbench.colorTheme": "Default High Contrast",
    "cmake.configureOnOpen": true,
    "C_Cpp.default.intelliSenseMode": "gcc-arm64",
    "jupyter.enableExtendedKernelCompletions": true,
    "C_Cpp.intelliSenseEngineFallback": "Enabled",
    "C_Cpp.legacyCompilerArgsBehavior": true,
    "cmake.configureSettings": {
    
    },
    "cortex-debug.dbgServerLogfile": ""
}

My launch.json (note that I changed “external” to “pyocd” in the servertype after reading Cortex-Debug for Visual Studio Code | Alone on a Mountaintop):

{
    "configurations": [
	{
	    "type": "cortex-debug",
	    "name": "Connect to GDB Example MAX32620FTHR Debug",
	    "executable": "/Users/howardharkness/arm-workspace/build/Example.elf",
	    "cwd": "${workspaceRoot}",
	    "gdbPath": "/opt/homebrew/bin/arm-none-eabi-gdb",
		"objdumpPath": "/opt/homebrew/bin/arm-none-eabi-objdump",
		"servertype": "pyocd",
		"gdbTarget": "localhost:23331",
		"request": "attach"
	},
    ]
}

There are a bunch more settings listed on that webpage that I have not yet figured out.

My mbed_app.json:

{
    "target_overrides": {
         "*": {
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-buffered-serial": 1,
            "target.printf_lib": "std"
        }
    }
}

My CMakeLists.txt:

cmake_minimum_required(VERSION 3.24)
cmake_policy(VERSION 3.24)
#enable firmware upload and remote debugging
set(PYOCD_UPLOAD_ENABLED TRUE)
set(PYOCD_TARGET_NAME max32620)
set(PYOCD_CLOCK_SPEED 4000k)

# Initialize Mbed OS build system.
# Note: This block must be before the include of app.cmake
set(MBED_APP_JSON_PATH mbed_app.json)

include(mbed-os/tools/cmake/app.cmake)
add_subdirectory(mbed-os)

project(Example)

# add subdirectories and build targets here
add_executable(Example Example.cpp)
target_link_libraries(Example mbed-baremetal)
mbed_set_post_build(Example)
mbed_finalize_build()

but the gdbserver was running, the error msg was about the gdb.
Can

/opt/homebrew/bin/arm-none-eabi-gdb

be started in a seperate console?

1 Like

Ok, that does start:

howardharkness@FT-Macbook-Pro ~ % /opt/homebrew/bin/arm-none-eabi-gdb
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 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-apple-darwin10 --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)

That brings up the debugger – and appears to stop the execution of the remote application on the MAX32620FTHR, presumably via a breakpoint mechanism. How do I get from there to setting breakpoints and stepping through the application using VSCode IDE?

I guess I can get back up to speed on using command-line gdb (last used by me about 15 years ago), and I probably should, but I’d rather do debugging in the IDE.

Did you read the wiki above? Probably not.

1 Like

that was just a test that the components are working. But usually, cmake checks this during configuration and it should work.

Using gdb manually is not the benefit of all this effort. It should work when the debug session is selected in the view/Run (ctrl-shift-D), then in top left select ’ Connect to GDB Example MAX32620FTHR Debug’ in the drop down and press the little green go button.

It should work with servertype ‘pyocd’ or ‘external’ and gdbserver started via ninja. It is also possible to add both configurations and select before starting the debugger.

1 Like

I believe that the server type has to be ‘external’, not ‘pyocd’. This tells it to connect to the pyocd instance that you start via ninja gdbserver, instead of starting a new instance.

1 Like

ninja knows a lot via cmake, I think this has some advantages, otherwise its manual configuration. But I have used the pyocd/stlink/stutil/bmp servertypes many times before and they worked also very well. As I said, now with the F746 I have also some trouble with the external servertype. But its the first time I tried, I will continue testing.
And the last error msg came from gdb, thats strange. The arm-none-eabi-gdb is working.

1 Like

Looks like I forgot to “save” that change anyway, and it reverted to “external”.