Closed ijager closed 4 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.
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
I encountered the same issue. Does someone already found a fix ?
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.
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.
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....
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 ?
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?
@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
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"
}
]
}
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"
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.
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.
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
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.
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
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: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:
The extension crashes on this line, reporting.ts:105:
Since
sessionStart
isnull
(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