New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to debug embedded remote targets using arm-none-eabi-gdb on Windows (path issues) #706
Comments
@gojimmypi They should work for windows if your target is not Linux. You can view what we send by enabling the following block in
The engineLogging will show the calls we send to If possible, can you enable the logging and share the results? |
@pieandcakes thanks for your reply & suggestion.
well, I have a somewhat convoluted setup here using both. As VSCode apparently does not have its own OpenOCD, I actually have OpenOCD running on an Ubuntu VM, with the JTAG connector & hardware. Feature request to not have to do that! :) However VSCode is on Windows, pointing at a local Windows directory with a copy of the source code & elf file (compiled on Ubuntu)... and doing a remote connection over the local (VM) network. For more of an explanation, see: https://gojimmypi.blogspot.com/2017/05/vscode-remote-debugging-of-embedded.html Per your request, my new
results in this log and error:
A quick Ctrl-H to replace the double-black-slashes with single-forward-slashes:
has a much different result:
|
See also issue #696 |
This is very similar to issue #328 however the problems I am experiencing are on Windows.
I am using the Atmel Studio 7
arm-none-eabi-gdb.exe
found in my:C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\arm\arm-gnu-toolchain\bin
However I believe there's a problem with spaces in the path, as even when escaping the path like this:
"miDebuggerPath": "C:\\Program Files (x86)\\Atmel\\Studio\\7.0\\toolchain\\arm\\arm-gnu-toolchain\\binarm-none-eabi-gdb.exe",
I will receive an error:
Unable to start debugging. The value of miDebuggerPath is invalid
So I moved the exe to my project path:
"miDebuggerPath": "C:\\workspace\\opendps\\opendps\\arm-none-eabi-gdb.exe",
I used the sample
launch.json
in issue #328 as a template and created this one:Notice I have OpenOCD running on a Ubuntu VM (in VMWare not WSL)... when debugging with F5 with the above VSCode returns this error:
Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "file 'C:\\workspace\\opendps\\opendps\\opendps.elf'"". C:workspaceopendpsopend...
Note how the path is mashed without slash delimiters at the end of the error. No additional information is available. Debug window is blank. See attached.
for reference, I am using the code found here: https://github.com/kanflo/opendps and I otherwise have the Ubuntu version of arm-none-eabi-gdb debugging properly with the given elf file from within the VM. I am also able to use the Atmel Studio arm-none-eabi-gdb.exe from within a DOS window to connect to the OpenOCD server and debug successfully. So the problem seems to be specific to VSCode.
edit: The Windows / Atmel Studio
arm-none-eabi-gdb.exe --version
returns:edit 2: it seems that if windows paths are instead entered using forward slashes, instead of escaped backslashes, the error does not occur, even with spaces in the path:
"miDebuggerPath": "C:/Program Files (x86)/Atmel/Studio/7.0/toolchain/arm/arm-gnu-toolchain/bin/arm-none-eabi-gdb.exe",
I'm not sure if this is as intended so I will not close this issue at this time. The docs here:
https://code.visualstudio.com/docs/languages/cpp#_debugging
and
https://github.com/Microsoft/vscode-cpptools/blob/master/launch.md
seem to indicate that either forward slashes (for Linux) and escaped backslashes (for Windows) should work.
The text was updated successfully, but these errors were encountered: