[Bredlej]

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.

Attachments:

You must be logged in to view attached files.

[Bredlej]

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 –>

Attachments:

You must be logged in to view attached files.

[Bredlej]

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.

Attachments:

You must be logged in to view attached files.

[Bredlej]

Hello, thanks for your assistance in trying to resolve this issue.

I did those steps you’ve written and here are the results:

1. 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 –>

[Bredlej]

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 –>

[Bredlej]

Oh all right, got a bit confused there, thanks!

[Author]

Posts