Visual Studio Code development with gcc and openocd

[Davide]

Hello,

I'm migrating all my projects from Eclipse to VSCode. On Eclipse I used to debug using JLink tools, however I would like to have a more generic tool (not all the devkits I use are equipped with a jlink debugger). I found openocd together with arm-none-eabi-gdb to be a good choice since it supports a number of MCUs and devkits that I use often.

Now, I already made it work for a third party manufacturer's MCU (therefore the installed tools look ok) and I'm trying to do the same for the Nordic's ones but I'm facing problems.

First of all, if I launch openocd from a terminal with the proper parameters (the same used by VScode) everything looks ok. Here the console:

giova@ubuntu-giova:~$ openocd -f board/nordic_nrf52_dk.cfg -c init -c "reset init"
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
openocd.org/.../bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 24 2017 17:30:12
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : Reduced speed from 10000 kHz to 1000 kHz (maximum).
Info : Reduced speed from 10000 kHz to 1000 kHz (maximum).
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000008e8 msp: 0x20000400

and if I run arm-none-eabi-gdb and then target remote localhost:3333 it connects to openocd without apparent errors.

However, when I launch the debug configuration from VScode, openocd starts properly (I see the same output of above) but then something goes wrong since gdb doesn't connect and the console tells is:

<-logout
Send Event AD7MessageEvent

Any idea on how to fix it? Unfortunately the console output is not really meaningful and I cannot say what component is complaining.

Davide

PS: my launch.json file is as follow:

{
    "version": "0.2.0",
    "configurations": [  
        {
            "name": "Debug Nordic",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/pca10040/s132/armgcc/_build/nrf52832_xxaa.out",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceRoot}/pca10040/s132/armgcc/",
            "environment": [],
            "externalConsole": false,
            "debugServerArgs":"-f board/nordic_nrf52_dk.cfg -c init -c \"reset init\"",
            "serverLaunchTimeout": 20000,
            "filterStderr": false,
            "filterStdout": false,
            "serverStarted": "target halted due to debug-request, current mode: Thread",
            "preLaunchTask": "build",
            "setupCommands": [
                { "text": "-target-select remote localhost:3333", "description": "connect to target", "ignoreFailures": false },
                { "text": "-file-exec-and-symbols ${workspaceRoot}/pca10040/s132/armgcc/_build/nrf52832_xxaa.out", "description": "load file", "ignoreFailures": false},
                { "text": "-interpreter-exec console \"monitor endian little\"", "ignoreFailures": false },
                { "text": "-interpreter-exec console \"monitor reset\"", "ignoreFailures": false },
                { "text": "-interpreter-exec console \"monitor halt\"", "ignoreFailures": false },
                { "text": "-interpreter-exec console \"monitor arm semihosting enable\"", "ignoreFailures": false },
                { "text": "-target-download", "description": "flash target", "ignoreFailures": false }
            ],
            "logging": {
                "moduleLoad": true,
                "trace": true,
                "engineLogging": true,
                "programOutput": true,
                "exceptions": true
            },
            "linux": {
                "MIMode": "gdb",
                "MIDebuggerPath": "/usr/bin/arm-none-eabi-gdb",
                "debugServerPath": "/usr/local/bin/openocd"
                //"debugServerPath":"/opt/SEGGER/JLink/JLinkGDBServer"
            },
            "osx": {
                "MIMode": "gdb",
                "MIDebuggerPath": "/usr/local/bin/arm-none-eabi-gdb",
                "debugServerPath": "/usr/local/Cellar/open-ocd/0.10.0/bin/openocd"
            },
            "windows": {
                "preLaunchTask": "mbed",
                "MIMode": "gdb",
                "MIDebuggerPath": "C:\\Program Files (x86)\\GNU Tools ARM Embedded\\4.9 2015q3\\bin\\arm-none-eabi-gdb.exe",
                "debugServerPath": "openocd.exe",
                "setupCommands": [
                    { "text": "-environment-cd ${workspaceRoot}\\DISCO_F413ZH\\GCC_ARM\\BUILD" }, //what's this?
                    { "text": "-target-select remote localhost:3333", "description": "connect to target", "ignoreFailures": false },
                    { "text": "-file-exec-and-symbols ${workspaceRootFolderName}.elf", "description": "load file", "ignoreFailures": false},
                    { "text": "-interpreter-exec console \"monitor endian little\"", "ignoreFailures": false },
                    { "text": "-interpreter-exec console \"monitor reset\"", "ignoreFailures": false },
                    { "text": "-interpreter-exec console \"monitor halt\"", "ignoreFailures": false },
                    { "text": "-interpreter-exec console \"monitor arm semihosting enable\"", "ignoreFailures": false },
                    { "text": "-target-download", "description": "flash target", "ignoreFailures": false }
                ]
            }
        },
  
    ]
  }

[Nguyen Hoan Hoang]

May I ask any particular reason why you switch to VS code instead of continuing with Eclipse?  Eclipse can work with OpenOCD and multiple MCU targets easily.  See here http://embeddedsoftdev.blogspot.com/p/idap-link.html for debugging nRF5x MCU with CMSIS-DAP and OpenOCD with Eclipse.

[Davide]

Three reasons:

1) eclipse is heavy to run, I don't have any data but VScode seems lighter. This is important because everything runs on a virtual machine, host is windows and guest is ubuntu.

2) I've put a lot of efforts to make eclipse recognizing all the symbols/include/declaration used in the code, but my projects are still full of red signs/warning/errors, even if gcc compiles perfectly. It is really annoying that the editor doesn't follow the compiler (yes I took a look at the tutorial here on the nordic, and yes I edited the providers string).

3) VScode projects and configurations are much more portable and clean, in particular when the code is on git like repository.

These reasons made me think about trying something else, and VScode was used by most of developers here.

[Nguyen Hoan Hoang]

Thanks for the insight.  Yeah, I know the red thing is quite annoying.  One way I found to reduce it is to go to project/C/C++ index/Rebuild.

I'll try VSCode when I get some free time.  It would be great if there is some kind of plugins similar to the GNU ARM eclipse.   

[Davide]

oh yes, I also tried index rebuild. When I read the tutorial I managed to make it work the first time, however after a while it stopped. I repeated all the steps several times but without luck.

For VSCode there is a jlink extension that should do the job for what concerns Nordic DKs (there are some related questions in this forum about it), however it can be applied only to jlink based boards. I would like a generic tool that can be configured also on other mcu, at least arm ones.

[Nguyen Hoan Hoang]

I think the problem was that used makefile project.  Eclipse native project works better.  Probably due to the fact that it does not have the include path.  While native project have all the paths to resolve the missing definition.  I use only native Eclipse project.  It works fine for me.  Nonetheless, I am still interested to find a way to add support of VS code to this multiplatform multiarchitecture library github.com/.../IOsonata 

[Davide]

Yes probably with native project the symbols are much easier to get recognized, but then it is really hard to synchronize the project on git. You can just push all the .project files, but then absolute path might brake at every pull, and diff operation would work badly. With makefiles the synchronization of project is much cleaner and again, once you understood the makefile configuration for an ARM MCU model, it is almost the same on the others.

I have been really a fan of Eclipse in the past years, but for me it is time to try something else.