Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
1.01k stars 240 forks source link

Failed to launch OpenOCD GDB Server: Timeout. #81

Closed ijager closed 4 years ago

ijager commented 6 years ago

I am trying to use this extension to debug a LPC4337 board via OpenOCD. However I have no luck yet getting it working.

From the same directory using the command line I can start an openOCD session and fire up GDB which works fine.

This is my launch.json configuration:

 "configurations": [
        {
            "showDevDebugOutput": true,
            "type": "cortex-debug",
            "request": "attach",
            "servertype": "openocd",
            "cwd": "${workspaceRoot}",
            "executable": "./build/blinky_m4",
            "name": "Cortex Debug",
            "device": "LPC43xx",
            "configFiles": [
                "interface/ftdi/jtag-lock-pick_tiny_2.cfg",
                "./lpc4337_jtag.cfg"
            ],
        }
    ]

VSCode gives me the following error when I try to run the debugger: Failed to launch OpenOCD GDB Server: Timeout.

And in the developer console I see this output:

[marus25.cortex-debug]Cannot read property 'getTime' of null
e.$onExtensionRuntimeError @ /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:3227
/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/workbench.main.js:3227 TypeError: Cannot read property 'getTime' of null 
at Object.endSession (../out/src/reporting.js:94:52)
at CortexDebugExtension.debugSessionTerminated (../out/src/frontend/extension.js:299:29)

The extension crashes on this line, reporting.ts:105:

    const time = (endTime.getTime() - sessionStart.getTime()) / 1000;

Since sessionStart is null (Is that a situation that should be possible?). I am not sure what that means, I guess it wasn't able to successfully start a debugging session?

What I can see is that OpenOCD does start properly (the led on my jtag device starts blinking and OpenOCD is briefly in my process list), but GDB does not appear in my process list. Am I missing something? I am willing to investigate further but I don't really know where to start since there is so little feedback/output. Any suggestions are appreciated.

MacOS 10.13.6 VSCode 1.26.1 OpenOCD 0.10 GDB: GNU gdb (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 8.1.0.20180315-git

chetferry commented 6 years ago

The cortex-debug extension used to work great for me. I am now on the latest MacOs and am not able to get it working any more. I get a message that says:

Failed to launch undefined GDB Server: Timeout.

MacOS 10.13.6 vscode 1.26.1 Jlink 6.34b Compiler gcc-arm-none-eabi-7-2018-q2-update

My launch.json file has this:

{ "version": "0.2.0", "configurations": [

    {
        "type": "cortex-debug",
        "request": "launch",
        "servertype": "jlink",
        "cwd": "${workspaceRoot}",
        "executable": "${workspaceRoot}/build/f767_rtos_test.elf",
        "svdFile": "${workspaceRoot}/STM32F7x7_v1r2.svd",
        "name": "Debug (J-Link)",
        "device": "STM32F767ZI",
        "interface": "swd",
        "ipAddress": null,
        "serialNumber": null
    }
]

}

I know the target and cable are all good. When I use Segger Ozone it all works correctly.

busticated commented 5 years ago

i'm hitting this now as well.

after launching into debug mode (green "play" button in the debug view), i see an error notification bottom-right that reads: Debug adapter process has terminated unexpectedly (read ECONNRESET) and my debug session never launches.

when i open dev tools (Help > Toggle Developer Tools), i see this error:

TypeError: Cannot read property 'getTime' of null
    at Object.endSession (./marus25.cortex-debug-0.1.21/out/src/reporting.js:94:52)
    at CortexDebugExtension.debugSessionTerminated (./marus25.cortex-debug-0.1.21/out/src/frontend/extension.js:299:29)
    at e.fire (./node/extensionHostProcess.js:133:218)

the adapter output log:

Open On-Chip Debugger 0.10.0 (2018-12-14-08:23)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.10
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x2ba01477
Info : stm32f2x.cpu: hardware has 6 breakpoints, 4 watchpoints

the open-ocd process is left running so trying to re-launch debug mode via the green "play" button yields:

Open On-Chip Debugger 0.10.0 (2018-12-14-08:23)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Error: couldn't bind tcl to socket: Address already in use

doing the same thing using the same configuration over on mac (high sierra), everything seems to work fine. i don't see an error, i'm able to pause at break-points, step-thru, etc.

i'm running: Ubuntu: 18.04.1 (LTS) VSCode: 1.30.0 Cortex Debug: 0.1.21

dylad commented 5 years ago

I encountered the same issue. Does someone already found a fix ?

democles9308 commented 5 years ago

Related Issue : can't even launch openOCD : Error Spawn openocd ENOENT linux MX 18 - openocd 0.10 - VSCode : 1.30.0 (flatpak) - cortex-debug 0.1.21

launch.json:

"version": "0.2.0", "configurations": [ { "cwd": "${workspaceRoot}", "executable": "/home/democles/Documents/Projects/STMdrone/.pioenvs/genericSTM32F103C8/firmware.elf", "name": "Debug OPENOCD", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "device":"STM32F103C8", "configFiles": ["/usr/local/share/openocd/scripts/interface/stlink-v2.cfg","/usr/local/share/openocd/scripts/target/stm32f1x.cfg"], }

Openocd build from source with ./configure --enable-stlink and intalled in /usr/local/bin:

openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2.cfg -f /usr/local/share/openocd/scripts/target/stm32f1x.cfg Open On-Chip Debugger 0.10.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 1000 kHz adapter_nsrst_delay: 100 none separate Info : Unable to match requested speed 1000 kHz, using 950 kHz Info : Unable to match requested speed 1000 kHz, using 950 kHz Info : clock speed 950 kHz Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 3.213613 Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

usr/local/bin is in the $PATH...

$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin

even when I put the path in the cortex-debug.openocdPath via the settings, I still got the spawn error..

Any help much apreciated.

efryters commented 5 years ago

I have a similar error as @busticated mentioned. It turns out that 18.04 Ubuntu does not have the GDB executable arm-none-eabi-gdb, so the extention hangs on debug. (https://askubuntu.com/questions/1031103/how-to-install-gdb-arm-none-eabi-on-ubuntu-18-04/1033056) My workaround was: 1) Apt install package: gdb-multiarch (Since normal GDB doesn't support ARM) 2) Add symbolic link

$ sudo ln -s /usr/bin/gdb-multiarch /usr/bin/arm-none-eabi-gdb

OR edit launch.json to point to the gdb-multiarch

        {
            "name": "Cortex Debug OpenOCD",
            "cwd": "${workspaceRoot}",
            "executable": "./build/aero2_firmware.elf",
            "request": "attach",
            "type": "cortex-debug",
            "servertype": "openocd",
             ........
            "showDevDebugOutput": false,
            "gdbpath": "/usr/bin/gdb-multiarch"
        },

3) Try to debug again And that seemed to work for me but now I've got a new issue during debug where when the execution is broken at a breakpoint, I can change my tabs or view to anything else. It immediately snaps back to the line of code where it paused.

democles9308 commented 5 years ago

Thanks for reply, FWIW, the arm-none-eabi toolchain is installed when you install cortex-debug,together with other tools (openocd etc) ( have a look in the .platformio/packages directories. The problem remains to open the openocd... I changed back to mint linux and did a fresh install and on this platform I always get timeouts from the GDB ( when using the cortex-debug plugin). Strange because everything works when I launch the process manually (i.e start openocd from a terminal and start the gdb from another terminal). So there must be something with the plugin as I'm using the provided tools. As extra I installed eclipse and there everything works also. Sad... I'd love to use visual studio code with the cortex plugin....

democles9308 commented 5 years ago

Strange, To doublecheck with eclipse, I installed the GNU MCU eclipse toolchain and openocd. This works fine in eclipse but by interest I went back to visual code studio with cortex-debug and tried the debugger by using the GNU MCU eclipse toolchain /openocd... and guess what... no timeout to connect error, but a working environment... One minor thing to solve... Its seems that I have always to reconfiure the launch.json file with my cortex-debug(openocd) setting. Is it rewritten by platformio by the start up ?

dhinault commented 5 years ago
      Strange,

To doublecheck with eclipse, I installed the GNU MCU eclipse toolchain and openocd. This works fine in eclipse but by interest I went back to visual code studio with cortex-debug and tried the debugger by using the GNU MCU eclipse toolchain /openocd... and guess what... no timeout to connect error, but a working environment... One minor thing to solve... Its seems that I have always to reconfiure the launch.json file with my cortex-debug(openocd) setting. Is it rewritten by platformio by the start up ?

have the same error "error Spawn Openocd ENOENT ", How did you solve the problem?

democles9308 commented 5 years ago

@dhinault,

I installed the GNU MCU eclipse toolchain and Openocd as explained on the site and used these versions in the settings of cortex-debug via file > preferences> settings/Extensions/cortex-debug For the arm toolchain path I've thefollowing: { "terminal.integrated.rendererType": "dom", "cortex-debug.openocdPath": "/home/democles/opt/gnu-mcu-eclipse/openocd/0.10.0-10-20181020-0522/bin/openocd", "cortex-debug.enableTelemetry": false, "cortex-debug.stutilPath": "/home/democles/.platformio/packages/tool-stlink/bin/st-util", "cortex-debug.armToolchainPath": "/home/democles/opt/gnu-mcu-eclipse/arm-none-eabi-gcc/8.2.1-1.1-20190102-1122/bin", "workbench.iconTheme": "vscode-icons", "workbench.colorTheme": "Solarized Dark", } my launch.json file looks like: { "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/.pioenvs/genericSTM32F103C8/firmware.elf", "name": "Debug Microcontroller", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "device": "STM32F103C8", "configFiles": ["/home/democles/opt/gnu-mcu-eclipse/openocd/0.10.0-10-20181020-0522/scripts/interface/stlink-v2.cfg","/home/democles/opt/gnu-mcu-eclipse/openocd/0.10.0-10-20181020-0522/scripts/target/stm32f1x.cfg"] } Hope this helps you

userFromHades commented 5 years ago

I've got the same error message. But indeed open ocd starts. I can see how led diode blinks on my st-link. I see a process in "ps aux | grep openocd".

At the same time in debug console appears record Launching server: "/usr/bin/openocd" "-c" "gdb_port 50000" "-s" "/home/user/work/osciloscope/src/firmware" "-f" "openocd.cfg"

If i run openocd manually by command /usr/bin/openocd -c gdb_port 50000 -s /home/user/work/osciloscope/src/firmware -f openocd.cfg it is working normally.

Ubuntu 19.04

VS Code

Version: 1.38.1
Commit: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
Date: 2019-09-11T13:30:08.229Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Linux x64 5.0.0-31-generic snap

launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "cwd": "${workspaceRoot}",
            "executable": "{workspaceFolder}/../../build/firmware.elf",
            "name": "Debug Microcontroller",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "openocd",
            "svdFile": "STM32F103xx.svd",
            "configFiles": [
                "openocd.cfg"
            ],
            "showDevDebugOutput": true,
            "gdbpath": "/usr/bin/gdb-multiarch"
        }
    ]
}
haneefdm commented 5 years ago

If you are seeing a spawn error with ENOENT it means Cortex-Debug could not find the OpenOCD executable. In your user-level settings.json or your workspace level .vscode/settings.json, you will need something like.

"cortex-debug.openocdPath": "/Applications/ModusToolbox_2.0/tools_2.0/openocd/bin/openocd"

But if you are seeing openocd running with ps aux then that is not the same problem. There are multiple (possibly different) errors/issues reported above so I can't tell which ones you are seeing specifically

If you are starting OpenOCD manually, then the quotes are still important especially if spaces are involved like for the "gdb_port 50000"

keithpenney commented 4 years ago

I ran into the same problem using openocd as a CLI. Big caveat - I am using an unofficial binary:

OpenOCD 0.10.0 commit date: 2017-01-22 20:31:28 build date: 2017-01-23 Windows 10 (x64)

Using an STM32F4-Discovery board (STM32F407VGT6) with latest ST-Link firmware V2.J34.M25, I tried openocd -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg and it hangs just before establishing the GDB/telnet servers. The last info text says,

Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Cranking up the debug level to 3 with -d, it looks like it hangs somewhere around the PLD initialization stage (which should be a no-op for this target). The last debug text is,

Debug: 385 6528 pld.c:205 handle_pld_init_command(): Initializing PLDs...

It's not unresponsive - still catches process kill (Ctrl+C) and cleanly exists with,

Debug: 386 523794 hla_interface.c:117 hl_interface_quit(): hl_interface_quit

An interesting side note, if I don't actually attempt to start the GDB/telnet server, it will happily run a jimtcl script successfully. E.g.:

openocd -f interface/stlink-v2-1.cfg -f target/stm32f4x.cfg -c "program filename.elf verify reset exit"

works fine.

It'd be great to integrate openocd fully into my toolchain, but I'm just going to switch to ST's utilities for now. Gotta get the job done.

haneefdm commented 4 years ago

All OpenOCD's are unofficial nowadays. Every vendor is releasing their own version and that is fine. If it works for you manually, then it should work with this extension.

You have to set the configFiles to ["interface/stlink-v2-1.cfg", "target/stm32f4x.cfg"] in launch.json. You may also have to set the search path as well using searchDir Check the debug console for command line used for openocd.

haneefdm commented 4 years ago

You don't need to do -c "program filename.elf verify reset exit" as that is done by this extension via gdb monitor commands. You can customize additional commands using pre/post/override launch/attach/restart options in launch.json

keithpenney commented 4 years ago

I'm not using it as a plugin. It's just part of my CLI toolchain, so no launch.json involved. And I can't use GBD monitor commands if the server isn't starting.

haneefdm commented 4 years ago

This extension starts the GDB server (openocd).

I have no idea what your flow is. No launch.json means you are not using this extension or even VSCode and your question is meant for someone else. Not for this repo.

This repo is for VSCode + this extension and aimed at debugging ARM 32-bit Cortex devices