Vscode-cpptools: Unable to debug embedded targets using arm-none-eabi-gdb

[Gussy]

I'm trying to set up debugging of a microcontroller using an external debug probe inside of vscode.

The following commands let me debug normally in the terminal, but I'm having trouble getting it to work inside vscode.

arm-none-eabi-gdb miniblink.elf
(gdb) file miniblink.elf
(gdb) target extended-remote /dev/cu.usbmodemD5D7A9C1
(gdb) monitor tpwr enable
(gdb) monitor swdp_scan
(gdb) attach 1

My vscode launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "cppdbg",
            "request": "launch",
            "miDebuggerPath": "/usr/local/bin/arm-none-eabi-gdb",
            "targetArchitecture": "arm",
            "program": "${workspaceRoot}/miniblink.elf",
            "setupCommands": [
                {"text": "file '${workspaceRoot}/miniblink.elf'"},
                {"text": "target extended-remote /dev/cu.usbmodemD5D7A9C1"},
                {"text": "monitor tpwr enable"},
                {"text": "monitor swdp_scan"},
                {"text": "attach 1"}
            ],
            "launchCompleteCommand": "None",
            "filterStderr": false,
            "filterStdout": false,
            "externalConsole": false,
            "cwd": "${workspaceRoot}"
        }
    ]
}

The output I get in the vscode debug console:

WARNING: Debugger executable '/usr/local/bin/arm-none-eabi-gdb' is not signed. As a result, debugging may not work properly.

=thread-group-added,id="i1"
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
Copyright (C) 2013 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".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Loaded 'shared libraries loaded at this time.'. Cannot find or open the symbol file.
Note: automatically using hardware breakpoints for read-only addresses.

My OS is Mac OS 10.11.6 and vscode version is 1.6.1.

[pieandcakes]

@Gussy I see the top warning:
WARNING: Debugger executable '/usr/local/bin/arm-none-eabi-gdb' is not signed. As a result, debugging may not work properly.

I don't know if that might be part of the issue. The other option would be to try and start gdb in MI mode from a command line and try the commands and see if it still works? You can get the list of commands we send by enabling the logging functionality in launch.json and paste them in there and see if there's more information:
"logging": { "engineLogging": true }

[Gussy]

Thanks for the logging tip @pieandcakes, that's perfect.

The only places where the output differs, are in these two snippets (with logging formatting and noise removed)

vscode:

1006-interpreter-exec console "attach 1"
~"Attaching to program: [redacted]/miniblink/miniblink.elf, Remote target\n"
=thread-group-started,id="i1",pid="1"
=thread-created,id="1",group-id="i1"
1006^done
(gdb)
1007-gdb-set solib-search-path [redacted]/miniblink:
*stopped,frame={addr="0x080001bc",func="main",args=[],file="miniblink.c",fullname="[redacted]/miniblink/miniblink.c",line="48"},thread-id="1",stopped-threads="all"
1007^done
(gdb)
1008-environment-cd [redacted]

And native gdb:

1006-interpreter-exec console "attach 1"
~"Attaching to program: [redacted]/miniblink/miniblink.elf, Remote target\n"
=thread-group-started,id="i1",pid="1"
=thread-created,id="1",group-id="i1"
1006^done
(gdb)
*stopped,frame={addr="0x080001cc",func="main",args=[],file="miniblink.c",fullname="[redacted]/miniblink/miniblink.c",line="51"},thread-id="1",stopped-threads="all"
1007-gdb-set solib-search-path [redacted]:
1007^done
(gdb)
1008-environment-cd [redacted]

Both are actually attaching and breaking on the code, which is good, but the only difference between the two logs is that the *stopped,[snip] line comes in a different place.

Could the response being received while it's sending the 1007[snip] command be causing a bug?

I also noticed in the logs that -exec-continue is being run at the end, even though I have "launchCompleteCommand": "None" in my launch.json.

[pieandcakes]

@Gussy We set a breakpoint at the entry point of main because in certain instances, we need to be at a stopped state to ensure our breakpoint bindings are all in place. Once that happens, it issues an -exec-continue. There currently isn't a work around to that. Is the continue breaking your scenario?

[Gussy]

I managed to get this working, thanks for the help @pieandcakes

The trick was to set at least one breakpoint (main is a good place, but location doesn't matter) before starting the debugger. Without at least one breakpoint, the debugger tools don't seem to initialise correctly.

It seems like the breakpoint at the entry point you mentioned isn't getting set in this case.

This is what my working launch.json looks like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "cppdbg",
            "request": "launch",
            "miDebuggerPath": "/usr/local/bin/arm-none-eabi-gdb",
            "targetArchitecture": "arm",
            "program": "${workspaceRoot}/output.elf",
            "setupCommands": [
                {
                    "text": "file '${workspaceRoot}/output.elf'"
                },
                {
                    "text": "target extended-remote /dev/cu.usbmodemXXXXXXXX"
                },
                {
                    "text": "monitor tpwr enable"
                },
                {
                    "text": "monitor swdp_scan"
                },
                {
                    "text": "attach 1"
                },
                {
                    "text": "load ${workspaceRoot}/output.elf"
                }
            ],
            "preLaunchTask": "make",
            "launchCompleteCommand": "None",
            "externalConsole": false,
            "cwd": "${workspaceRoot}"
        }
    ]
}

[kanflo]

Hi @pieandcakes. I too realised one needs to set a manual breakpoint (in the IDE, not in launch.json) for the debugger to attach successfully. Without the breakpoint, it will not be possible for VSCode to halt the target. Could this issue perhaps be reopened?

[ralphrmartin]

Still getting this problem, with code exported from mbed.

[pieandcakes]

@ralphrmartin If you can provide me a repro log I can take a look ("logging": { "engineLogging": true } in launch.json). I don't have a microcontroller or a setup to test it with, so this isn't a scenario I'm familiar enough with.

[ralphrmartin]

I finally fixed the problem. The issue (not described on the mbed website) was that you need to look out for the text the gdb server sends when it is ready.

See bug raised here and my solution:
https://os.mbed.com/forum/bugs-suggestions/topic/28935/

[pieandcakes]

@ralphrmartin awesome! thanks for sharing the solution.