- This topic has 11 replies, 2 voices, and was last updated 1 year, 5 months ago by
.
-
Posts
-
Hello,
I’ve upgraded my VisualGDB from Embedded to Linux edition (v5.6R8 build 4702), and want to flash my Pico via remote OpenOCD through a Raspberry Pi.
I’m using Microsoft Visual Studio Community 2022 (64-bit) Version 17.0.4.
I managed to establish an ssh connection to the RPI, but the debugger won’t run for some reason.
Pressing the “Test” button results immediately in the following exception:
VisualGDB version: 5.6.108.4702 ------------------ System.Exception ------------------ System.Exception: Stub exited before a gdb connection could be made w VisualGDB.Common_GUI.WPF.DebugMethodTestWindow.ThrowTestFailedException() w VisualGDB.Common_GUI.WPF.DebugMethodTestWindow.TestThreadBody() trace=[VisualGDB.Common_GUI.WPF.DebugMethodTestWindow.ThrowTestFailedException:56, VisualGDB.Common_GUI.WPF.DebugMethodTestWindow.TestThreadBody:211]
When trying to run the program from Visual Studio I get the following log entry:
openocd -c "gdb_port 55172" -c "telnet_port 55170" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" c:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe --interpreter mi "C:/Users/geoco/source/repos/PicoSDKProject3/PicoSDKProject3/build/VisualGDB/Debug/blink.elf" [ 0 ms] -gdb-version [ 26 ms] c:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. [ 41 ms] =thread-group-added,id="i1" [ 42 ms] ~"GNU gdb (GDB) 10.2.90.20210621-git\n" [ 42 ms] ~"Copyright (C) 2021 Free Software Foundation, Inc.\n" [ 42 ms] ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law." [ 42 ms] ~"\nType \"show copying\" and \"show warranty\" for details.\n" [ 42 ms] ~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".\n" [ 42 ms] ~"Type \"show configuration\" for configuration details.\n" [ 42 ms] ~"For bug reporting instructions, please see:\n" [ 42 ms] ~"<https://www.gnu.org/software/gdb/bugs/>.\n" [ 42 ms] ~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>." [ 42 ms] ~"\n\n" [ 42 ms] ~"For help, type \"help\".\n" [ 42 ms] ~"Type \"apropos word\" to search for commands related to \"word\"...\n" [ 43 ms] ~"Reading symbols from C:/Users/geoco/source/repos/PicoSDKProject3/PicoSDKProject3/build/VisualGDB/Debug/blink.elf...\n" [ 46 ms] ~"GNU gdb (GDB) 10.2.90.20210621-git\n" [ 46 ms] ~"Copyright (C) 2021 Free Software Foundation, Inc.\n" [ 46 ms] ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law." [ 46 ms] ~"\nType \"show copying\" and \"show warranty\" for details.\n" [ 46 ms] ~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".\n" [ 46 ms] ~"Type \"show configuration\" for configuration details.\n" [ 46 ms] ~"For bug reporting instructions, please see:\n" [ 46 ms] ~"<https://www.gnu.org/software/gdb/bugs/>.\n" [ 46 ms] ~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>." [ 46 ms] ~"\n\n" [ 46 ms] ~"For help, type \"help\".\n" [ 46 ms] ~"Type \"apropos word\" to search for commands related to \"word\".\n" [ 46 ms] ^done [ 46 ms] -list-features [ 46 ms] ^done,features=["frozen-varobjs","pending-breakpoints","thread-info","data-read-memory-bytes","breakpoint-notifications","ada-task-info","language-option","info-gdb-mi-command","undefined-command-error-code","exec-run-start-option","data-disassemble-a-option"] [ 46 ms] -gdb-set verbose on [ 72 ms] ^done [ 72 ms] -gdb-set disassembly-flavor intel [ 87 ms] ^error,msg="No symbol \"disassembly\" in current context." [ 87 ms] ^error,msg="No symbol \"disassembly\" in current context." [ 87 ms] -gdb-set print demangle off [ 87 ms] ^done [ 88 ms] set remotetimeout 60 [ 102 ms] &"set remotetimeout 60\n" [ 102 ms] =cmd-param-changed,param="remotetimeout",value="60" [ 102 ms] ^done [ 102 ms] target remote chani:55172 [ 102 ms] &"target remote chani:55172\n" [ 16462 ms] &"chani:55172: Connection timed out.\n" [ 16462 ms] ^error,msg="chani:55172: Connection timed out." [ 16462 ms] &"Quit\n"When I run the same prompt from my Raspberry Pi it works:
<!--StartFragment -->
❯ openocd -c "gdb_port 55172" -c "telnet_port 55170" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz adapter speed: 3000 kHz Warn : Transport "swd" was already selected swd Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 3045 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 55172 Info : Listening on port 55172 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 VisualGDB_OpenOCD_Ready Info : Listening on port 6666 for tcl connections Info : Listening on port 55170 for telnet connections <!--EndFragment -->So it seems altough the ssh connection is ok, it can’t connect with GDB to my Raspberry Pi for some reason.
Do you have any ideas why? I’ve tried restarting the PC and RPI, and also installing OpenOCD on my RPI as described here Getting started with Raspberry Pi Pico (chapter 5)
Same thing happens with my other RPI.
Also where can I set the port 55172 used for the connection?
I’ll be happy to provide more information if needed.
Hi,
This could indicate a network/firewall issue. Please try doing the following manually:
- Run OpenOCD on Raspberry Pi
- Run GDB on Windows
- Manually run the “target remote” command in GDB.
If the connection doesn’t work, please try changing the port to a lower value (e.g. 3000).
You can change the port number used by VisualGDB by setting the PreferredGDBPort element in the .vgdbsettings/.vgdbcmake file to a non-zero value. It will override the default logic of picking a random unused port.
Hi, so I did accordingly to your suggestion.
Here’s OpenOCD running in my Raspberry Pi:
<!--StartFragment -->
❯ openocd -c "gdb_port 55172" -c "telnet_port 55170" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz adapter speed: 3000 kHz Warn : Transport "swd" was already selected swd Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 3045 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 55172 Info : Listening on port 55172 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 VisualGDB_OpenOCD_Ready Info : Listening on port 6666 for tcl connections Info : Listening on port 55170 for telnet connections Info : accepting 'gdb' connection on tcp/55172 Info : RP2040 B0 Flash Probe: 2097152 bytes @10000000, in 512 sectors Info : New GDB Connection: 1, Target rp2040.core0, state: halted Warn : Prefer GDB command "target extended-remote 55172" instead of "target remote 55172" target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 Info : Writing 30608 bytes starting at 0x0 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00<!–EndFragment –>And GDB started from PowerShell on my PC:
<!–StartFragment –>
C:\Users\geoco\source\repos\PicoSDKProject3\PicoSDKProject3\build\VisualGDB\Debug> c:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe C:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. GNU gdb (GDB) 10.2.90.20210621-git Copyright (C) 2021 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=i686-w64-mingw32 --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file blink.elf Reading symbols from blink.elf... (gdb) target remote chani:55172 Remote debugging using chani:55172 warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread 0x000000ee in ?? () (gdb) load Loading section .boot2, size 0x100 lma 0x10000000 Loading section .text, size 0x6030 lma 0x10000100 Loading section .rodata, size 0x1368 lma 0x10006130 Loading section .binary_info, size 0x1c lma 0x10007498 Loading section .data, size 0x2dc lma 0x100074b4 Start address 0x100001e8, load size 30608 Transfer rate: 15 KB/sec, 5101 bytes/write. (gdb) c Continuing.
Seems like it works fine even when using a higher port number.
Do you perhaps have any other ideas for things I could try out?
<!–EndFragment –>
No problem. Please try the following:
- Start a debug session with VisualGDB and take a note of the debug port used by OpenOCD.
- When VisualGDB reports that it cannot connect to the target, press the “ignore” button. Do not stop the debug session, so that VisualGDB keeps OpenOCD running.
- While OpenOCD launched by VisualGDB is still running, try manually running gdb and connecting to the target.
If the manually initiated connection works, please double-check your firewall settings and try disabling it, as it might be specifically blocking the Visual Studio process and gdb launched by it.
If the manually initiated connection doesn’t work, please try ending the debug session in VisualGDB and immediately running OpenOCD with the same command line (please use the complete command line including all environment variables from View->Other Windows->VisualGDB Diagnostics Console).
Please let us know your findings and we will advise you on further diagnostic steps.
Hello, thanks for your assistance in trying to resolve this issue.
I did those steps you’ve written and here are the results:
- Started VisualGDB and pressed ignore – port was 58644
[+23026] ExecuteRawCommand(-gdb-exit, b) [+4] GDB command result:^exit Applying Live Watch filter results: 0 msec Launching gdbserver... SSH [8]: executing command: "openocd" -v SSH [8]: command exited with code 0 after 194 msec Embedded Debug Start Service: running "openocd -c "gdb_port 58644" -c "telnet_port 58642" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"" on Remote hosting context for chani Run "openocd -c "gdb_port 58644" -c "telnet_port 58642" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"" in directory "" on pi@chani (SSH) [+4875] ExecuteRawCommand(-gdb-version, b) [+43] GDB command result:^done [+0] ExecuteRawCommand(-list-features, b) [+23] GDB command result:^done,features=["frozen-varobjs","pending-breakpoints","thread-info","data-read-memory-bytes","breakpoint-notifications","ada-task-info","language-option","info-gdb-mi-command","undefined-command-error-code","exec-run-start-option","data-disassemble-a-option"] [+0] ExecuteRawCommand(-gdb-set verbose on, b) [+16] GDB command result:^done [+0] ExecuteRawCommand(-gdb-set disassembly-flavor intel, b) [+16] GDB command result:^error,msg="No symbol \"disassembly\" in current context." [+0] ExecuteRawCommand(-gdb-set print demangle off, b) [+15] GDB command result:^done Creating live memory engine... Created a live memory evaluator: OpenOCDPackage.LiveMemoryEvaluator [+0] ExecuteRawCommand(set remotetimeout 1200, d) [+16] GDB command result:^done [+0] ExecuteRawCommand(target remote chani:58644, d) [+3571] GDB command timed out [+2987] ExecuteRawCommand(mon halt, d) [+9720] GDB command result:^error,msg="chani:58644: Connection timed out." [+1] ExecuteRawCommand(mon reset init, d) [+0] GDB command result:^error,msg="\"monitor\" command not supported by this target." [+1] ExecuteRawCommand(mon report_flash_progress 1, d) [+14] GDB command result:^error,msg="\"monitor\" command not supported by this target." [+7] ExecuteRawCommand(load, d) &"load\n" &"You can't do that when your target is `exec'\n" ^error,msg="You can't do that when your target is `exec'" (gdb) [+9] GDB command result:^error,msg="You can't do that when your target is `exec'" [+7] ExecuteRawCommand(-data-evaluate-expression "sizeof(void *)", b) [+9] GDB command result:^done,value="4" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(int)", b) [+0] GDB command result:^done,value="4" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(short)", b) [+0] GDB command result:^done,value="2" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(long)", b) [+0] GDB command result:^done,value="4" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(long long)", b) [+0] GDB command result:^done,value="8" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(char)", b) [+1] GDB command result:^done,value="1" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(wchar_t)", b) [+0] GDB command result:^error,msg="No symbol \"wchar_t\" in current context." [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(float)", b) [+0] GDB command result:^done,value="4" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(double)", b) [+0] GDB command result:^done,value="8" [+0] ExecuteRawCommand(-data-evaluate-expression "sizeof(long double)", b) [+0] GDB command result:^done,value="8" Importing C:\Users\geoco\AppData\Local\VisualGDB\PicoSDK\1.4.0-Package\src\rp2040\hardware_regs\rp2040.svd: 78 msec Applying Live Watch filter results: 0 msec Applying Live Watch filter results: 0 msec [+81] ExecuteRawCommand(info target, d) [+1] ExecuteRawCommand(-data-list-register-names, b) [+10] GDB command result:^done [+0] GDB command result:^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11","r12","sp","lr","pc","f0","f1","f2","f3","f4","f5","f6","f7","fps","cpsr","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""] [+1] ExecuteRawCommand(-data-list-register-values r-10, b) [+1] ExecuteFrameSensitiveCommand(-data-evaluate-expression "&_estack", -1, -1) [+0] ExecuteRawCommand(-data-evaluate-expression "&_estack", b) [+13] GDB command result:^error,msg="No registers." [+16] GDB command result:^error,msg="No symbol \"_estack\" in current context." [+0] ExecuteFrameSensitiveCommand(-data-evaluate-expression "&__StackTop", -1, -1) [+0] ExecuteRawCommand(-data-evaluate-expression "&__StackTop", b) [+0] GDB command result:^done,value="0x20042000" [+0] ExecuteFrameSensitiveCommand(-var-create - * "*((void **)0x20041ffc)", -1, -1) [+0] ExecuteRawCommand(-var-create - * "*((void **)0x20041ffc)", b) [+0] GDB command result:^done,name="var1",numchild="0",value="",type="void *",has_more="0" [+0] ExecuteRawCommand(-var-evaluate-expression "var1", b) [+16] GDB command result:^done,value="" [+0] ExecuteRawCommand(-break-insert -f main, b) [+16] GDB command result:^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x100003e6",func="main",file="../../../blink.c",fullname="C:\\Users\\geoco\\source\\repos\\PicoSDKProject3\\PicoSDKProject3\\blink.c",line="13",thread-groups=["i1"],times="0",original-location="main"} [+0] ExecuteRawCommand(-exec-continue, a) [+16] GDB command result:^error,msg="The program is not being run." [+0] GDB stop event received [+0] GDB stop event received [+4] ExecuteRawCommand(-data-list-register-values r-10, b) [+0] ExecuteFrameSensitiveCommand(-stack-list-frames, 1, -1) [+0] ExecuteRawCommand(-stack-list-frames --thread 1, b) [+12] GDB command result:^error,msg="No registers." [+15] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-stack-list-frames, b) [+16] GDB command result:^error,msg="No registers." [+0] ExecuteFrameSensitiveCommand(-stack-list-frames 0 0, 1, -1) [+0] ExecuteRawCommand(-stack-list-frames --thread 1 0 0, b) [+15] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-stack-list-frames 0 0, b) [+16] GDB command result:^error,msg="No registers." [+0] ExecuteFrameSensitiveCommand(-data-evaluate-expression "\$pc", 1, -1) [+0] ExecuteRawCommand(-data-evaluate-expression --thread 1 "\$pc", b) [+0] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-data-evaluate-expression "\$pc", b) [+0] GDB command result:^error,msg="No registers." Failed to query stack frames directly (likely due to reentrancy). Returning cached frame list. failed to query the frame list at qo1.EnumFrameInfo Full thread list requested (False) [+0] ExecuteFrameSensitiveCommand(-stack-list-frames, 1, -1) [+0] ExecuteRawCommand(-stack-list-frames --thread 1, b) [+16] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-stack-list-frames, b) [+0] GDB command result:^error,msg="No registers." [+0] ExecuteFrameSensitiveCommand(-stack-list-frames 0 0, 1, -1) [+0] ExecuteRawCommand(-stack-list-frames --thread 1 0 0, b) [+0] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-stack-list-frames 0 0, b) [+0] GDB command result:^error,msg="No registers." [+0] ExecuteFrameSensitiveCommand(-data-evaluate-expression "\$pc", 1, -1) [+0] ExecuteRawCommand(-data-evaluate-expression --thread 1 "\$pc", b) [+0] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-data-evaluate-expression "\$pc", b) [+0] GDB command result:^error,msg="No registers." Failed to query stack frames directly (likely due to reentrancy). Returning cached frame list. failed to query the frame list at qo1.EnumFrameInfo [+1] ExecuteFrameSensitiveCommand(-stack-list-frames, 1, -1) [+0] ExecuteRawCommand(-stack-list-frames --thread 1, b) [+15] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-stack-list-frames, b) [+0] GDB command result:^error,msg="No registers." [+0] ExecuteFrameSensitiveCommand(-stack-list-frames 0 0, 1, -1) [+0] ExecuteRawCommand(-stack-list-frames --thread 1 0 0, b) [+0] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-stack-list-frames 0 0, b) [+0] GDB command result:^error,msg="No registers." [+0] ExecuteFrameSensitiveCommand(-data-evaluate-expression "\$pc", 1, -1) [+0] ExecuteRawCommand(-data-evaluate-expression --thread 1 "\$pc", b) [+0] GDB command result:^error,msg="Invalid thread id: 1" [+0] ExecuteRawCommand(-data-evaluate-expression "\$pc", b) [+0] GDB command result:^error,msg="No registers." Failed to query stack frames directly (likely due to reentrancy). Returning cached frame list. failed to query the frame list at qo1.EnumFrameInfo at Microsoft.VisualStudio.Debugger.Interop.IEnumDebugFrameInfo2.Next at Microsoft.VisualStudio.Debugger.Interop.IEnumDebugFrameInfo2.Next at Microsoft.VisualStudio.Debugger.DebuggerToolWindows.NoSourceWindow.NoSourceToolWindow.CheckForExternalCodeFrame at Microsoft.VisualStudio.Debugger.DebuggerToolWindows.NoSourceWindow.NoSourceToolWindow.CreateModel at Microsoft.VisualStudio.Debugger.DebuggerToolWindows.NoSourceWindow.NoSourceToolWindow.LoadData at Microsoft.VisualStudio.Debugger.DebuggerToolWindows.NoSourceWindow.NoSourceToolWindowAdapter.ShowNoSourceToolWindow at Microsoft.VisualStudio.Debugger.DebuggerToolWindows.NoSourceWindow.NoSourceToolWindowAdapter.DebuggerEventsDebuggerEvent at System.RuntimeMethodHandle.InvokeMethod at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal at System.Reflection.RuntimeMethodInfo.Invoke at Microsoft.VisualStudio.Debugger.Utilities.Events.EventFire.Fire at Microsoft.VisualStudio.Debugger.Utilities.Events.EventFire.FireOrdered at Microsoft.VisualStudio.Debugger.Utilities.Debugger.DebuggerEvents.OnEvent at Microsoft.VisualStudio.Debugger.Utilities.Debugger.DebuggerEvents+DebuggerEventListener.Event [+34] ExecuteRawCommand(-data-list-register-values r-10, b) [+14] GDB command result:^error,msg="No registers." Full thread list requested (False)2. Attempted to manually connect to the target via GDB:
<!–StartFragment –>
<!--StartFragment -->
PS C:\Users\geoco> c:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe C:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. GNU gdb (GDB) 10.2.90.20210621-git Copyright (C) 2021 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=i686-w64-mingw32 --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) target remote chani:58644 chani:58644: Connection timed out. (gdb)<!--EndFragment -->
3. Stopped the debug session and invoked OpenOCD from RaspberryPi console with the same settings as VisualGDB:
<!--StartFragment -->
<!--StartFragment -->
❯ openocd -c "gdb_port 58644" -c "telnet_port 58642" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz adapter speed: 3000 kHz Warn : Transport "swd" was already selected swd Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 3045 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 58644 Info : Listening on port 58644 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 VisualGDB_OpenOCD_Ready Info : Listening on port 6666 for tcl connections Info : Listening on port 58642 for telnet connections<!--EndFragment -->
4. Attempted to connect again with GDB in PowerShell:
<!–StartFragment –>
PS C:\Users\geoco> c:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe C:\SysGCC\arm-eabi\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. GNU gdb (GDB) 10.2.90.20210621-git Copyright (C) 2021 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=i686-w64-mingw32 --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) target remote chani:58644 Remote debugging using chani:58644 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread 0x000000ee in ?? () (gdb) Quit
<!–EndFragment –>
So it seems to me that even if VisualGDB manages to run OpenOCD on the remote machine, it can’t connect to it via it’s own GDB.
But running GDB outside Visual Studio 2022/VisualGDB is connecting fine.I tried allowing VisualStudio 2022 to access public and private networks in the Windows Defender app, but I’m still getting this timeout.
If you need any further info I’ll be glad to provide.
<!–EndFragment –>
Hi,
If we understood you correctly, having VisualGDB launch OpenOCD on the target has no effect, but running it manually works.
If this is the case, please follow the steps below:
- Start a debug session with VisualGDB. Click “ignore” when it reports the error.
- Double-check the Debug->Windows->VisualGDB Output->OpenOCD window in Visual Studio. Does OpenOCD show any errors there? Is it still running?
- If OpenOCD appears running, can you see it on the target machine by running “sudo ps -ax”? If not, you might be running it on a different target.
- If OpenOCD exited with an error, what is the error message? Also are you doing anything different when launching it manually (e.g. running it under sudo or connecting the device differently)?
I’ve attached a screenshot of the debug session output.
In VisualGDB Output -> OpenOCD I only see the prompt:
openocd -c "gdb_port 54699" -c "telnet_port 54697" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
… and nothing else.
In the GDB session output I see it’s trying to connect to my Raspberry Pi (pi@chani) but it gets a timeout:
target remote chani:54699 &"target remote chani:54699\n" mon halt &"chani:54699: Connection timed out.\n" ^error,msg="chani:54699: Connection timed out." &"Quit\n" mon reset init &"mon halt\n" &"\"monitor\" command not supported by this target.\n"
I tried to replace the hostname “chani” with the machine’s IP address but it’s the same effect. It can connect via ssh, but pressing the “Test” button results in an immediate System.exception (attached second screenshot).
As to your 3rd question – it doesn’t seem that OpenOCD is being ran by VisualGDB on the RaspberryPi (3rd screenshot) – and yes it’s the same machine “chani”.
I’m not really doing anything different when running manually. I copied the same prompt VisualGDB uses (4rd screenshot):
openocd -c "gdb_port 54952" -c "telnet_port 54950" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Login per SSH to pi@chani and run it there (plain openocd call, without sudo or anything):
<!–StartFragment –>
❯ openocd -c "gdb_port 54952" -c "telnet_port 54950" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz adapter speed: 3000 kHz Warn : Transport "swd" was already selected swd Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 3045 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 54952 Info : Listening on port 54952 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 VisualGDB_OpenOCD_Ready Info : Listening on port 6666 for tcl connections Info : Listening on port 54950 for telnet connections
<!–EndFragment –>Seems that altough VisualGDB is able to connect via SSH to the machine as pi@chani, it’s for some reason unable to start openocd there.
I tried to reinstall VisualGDB but it didn’t change anything. My host-configurations were preserved though and I thought about purging it completely (so I would have to define new ssh connections, etc.), I’m just not sure about how to do it exactly.
I’m also thinking about reinstalling Visual Studio, yet I’m not sure this will help.
Some more info if it maybe helps in ideas for troubleshooting:
- PC is running on Windows 11 Home 21H2
- Raspberry Pi 4B is running on Linux 5.10.17-v7l+ armv7l (Raspbian GNU/Linux 10 (buster))<!–EndFragment –><!–EndFragment –>
- I have another RaspberryPi4B where I have the same issue
- I’m connecting to the RPI’s through Wi-Fi
- It worked once (about a year ago or so) when I used it with the trial version of VisualGDB
Do you have any ideas left? Your assistance is very much appreciated.
Thanks for checking this. The OpenOCD view under VisualGDB output should not be blank! It looks like OpenOCD actually never gets a chance to run when launched by VisualGDB.
It could happen if you had 2 different openocd executables in different directories and 2 incompatible values of the PATH variable for the SSH command mode (used by VisualGDB) and the SSH shell mode (used by regular shells).
You can try troubleshooting it further by setting the explicit path to the OpenOCD executable in VisualGDB Project Properties. If it doesn’t help, please try launching OpenOCD via SSH by running the following command from another Linux machine (or WSL):
ssh [user]@[ip address of Raspberry Pi] full-path-to-openocd <command line parameters>
If it doesn’t start a valid OpenOCD session (producing output), something about the SSH configuration is interfering with it.
You might be on to something …
I tried to select openocd manually in both “/usr/bin/openocd” and “/usr/local/bin/openocd” (1st screenshot) and there was the same error.
Next I’ve tried to run it through WSL as you’ve said and get the following result:
<!–StartFragment –>
❯ ssh pi@chani /usr/bin/openocd -c "gdb_port 54952" -c "telnet_port 54950" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" pi@chani's password: Open On-Chip Debugger 0.10.0+dev-00114-g41bcbc67d-dirty (2021-01-18-16:43) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Unexpected command line argument: 54952 ❯ ssh pi@chani /usr/local/bin/openocd -c "gdb_port 54952" -c "telnet_port 54950" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" pi@chani's password: Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Unexpected command line argument: 54952
Looks like it manages to start OpenOCD but doesn’t know how to parse the following arguments and exits with an error.
I’ll look for how to pass the arguments correctly through SSH.Have you perhaps tried it at your workstation? If yes I assume it works fine, or does it?
Anyways good catch!
<!–EndFragment –>
We have tested this on our side during the release process, so the issue is likely caused by some configuration specific to your Raspberry Pi image.
Either way, you would indeed need to escape the arguments to “ssh” so that the quotes are handled correctly (although it would not affect the way VisualGDB runs commands). An easier way would be to create a script file (e.g. /usr/bin/openocd-test), make it executable and place the command line in there:
#!/bin/sh echo TEST123 echo TEST456 > /tmp/test.txt /usr/bin/openocd <hardcoded arguments>
Then you can select this script as the OpenOCD executable in VisualGDB settings, and see if it works. Specifically, if it shows “TEST123” in the VisualGDB Output window and if it creates a /tmp/test.txt file as well.
The script will ignore the actual arguments passed to it, so you can test it on WSL by just running “ssh pi@chani /usr/bin/openocd-test”.
Ok I’ve created the file, marked it as chmod +x and set it as the manual start script inside VisualGDB.
Looks like the file is not executed on the raspberry, since there was no TEST123 output and the file /tmp/test.txt has not been created – which is a bummer.I’ve noticed that when running openocd through ssh from WSL, there’s a difference when I use double-quotes vs single apostrophes:
<!–StartFragment –>
❯ ssh pi@chani openocd -c "gdb_port 58644" -c "telnet_port 58642" -c "bindto 0.0.0.0" -f interface/raspberrypi-swd.cfg -c "adapter speed 3000" -c "transport select swd" -f target/rp2040.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready" Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Unexpected command line argument: 58644 ❯ ssh pi@chani "openocd -c 'gdb_port 58644' -c 'telnet_port 58642' -c 'bindto 0.0.0.0' -f interface/raspberrypi-swd.cfg -c 'adapter speed 3000' -c 'transport select swd' -f target/rp2040.cfg -c init -c 'reset init' -c 'echo VisualGDB_OpenOCD_Ready'" Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-11-02-19:53) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz adapter speed: 3000 kHz Warn : Transport "swd" was already selected swd Info : Hardware thread awareness created Info : Hardware thread awareness created Info : RP2040 Flash Bank Command Info : BCM2835 GPIO JTAG/SWD bitbang driver Info : clock speed 3045 kHz Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x00000001 Info : SWD DPIDR 0x0bc12477 Info : SWD DLPIDR 0x10000001 Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for rp2040.core0 on 58644 Info : Listening on port 58644 for gdb connections target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 target halted due to debug-request, current mode: Thread xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00 VisualGDB_OpenOCD_Ready Info : Listening on port 6666 for tcl connections Info : Listening on port 58642 for telnet connections
<!–EndFragment –>
Above the first invocation is what probably VisualGDB tries to do, and the second is where I’ve replaced the “s with ‘s.
Maybe it doesn’t matter much, but I’ve noticed that VisualGDB attaches it’s own generated parameters even when there where none specified.
Is there maybe a way to prohibit VisualGDB from adding own parameters? I’d like to try it out.
About the SSH configuration I’m not sure, but I think it’s a pretty standard SSH configuration from Raspbian – I don’t remember fiddling around there but I’ll have a look if there’s something weird going on.
What Raspberry OS are you using in your test environments if I may ask?
I’ll try see if there’s an upgrade available to the newest version of the OS on my RPI.
Hi,
We have just retested it with the latest Raspberry Pi Bullseeye image and it worked just fine.
Please try checking if running OpenOCD on another Linux box works. It doesn’t need to connect to the actual hardware – any output from OpenOCD (e.g. showing its version) indicates that it has launched successfully.
You can also try running sshd on your Raspberry Pi in foreground mode from a physical console:
sudo killall sshd sshd -d
This will force sshd to log every request issued by VisualGDB, so you can double-check whether VisualGDB attempts to launch OpenOCD and what arguments it uses.
- You must be logged in to reply to this topic.