Issue with running OpenOCD remotely on Raspberry Pi

Sysprogs forums Forums VisualGDB Issue with running OpenOCD remotely on Raspberry Pi

This topic contains 11 replies, has 2 voices, and was last updated by  support 3 weeks, 2 days ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #33363



    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:

    When trying to run the program from Visual Studio I get the following log entry:

    When I run the same prompt from my Raspberry Pi it works:

    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.




    This could indicate a network/firewall issue. Please try doing the following manually:

    1. Run OpenOCD on Raspberry Pi
    2. Run GDB on Windows
    3. 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:

    <!–EndFragment –>And GDB started from PowerShell on my PC:

    <!–StartFragment –>

    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:

    1. Start a debug session with VisualGDB and take a note of the debug port used by OpenOCD.
    2. 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.
    3. 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:

    1. Started VisualGDB and pressed ignore – port was 58644

    2. Attempted to manually connect to the target via GDB:

    <!–StartFragment –>

    3. Stopped the debug session and invoked OpenOCD from RaspberryPi console with the same settings as VisualGDB:

    4. Attempted to connect again with GDB in PowerShell:

    <!–StartFragment –>

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




    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:

    1. Start a debug session with VisualGDB. Click “ignore” when it reports the error.
    2. Double-check the Debug->Windows->VisualGDB Output->OpenOCD window in Visual Studio. Does OpenOCD show any errors there? Is it still running?
    3. 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.
    4. 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:

    … 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:

    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):

    Login per SSH to pi@chani and run it there (plain openocd call, without sudo or anything):

    <!–StartFragment –>

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

    You must be logged in to view attached files.


    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):

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

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

    You must be logged in to view attached files.


    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:

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

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

    You must be logged in to view attached files.



    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:

    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.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.