[support]

Hi,

Sorry, perhaps the other debugger is handling some USB requests differently. VisualGDB relies on OpenOCD to handle low-level debugging and we can confirm that it does not work very fast on VMs. Hence our best advice is to use a physical VM instead (or at least run OpenOCD on a physical machine, however that would require a complex manual setup).

[support]

Hi,

Are you using a VM with USB virtualization? If yes, slow debugging is to be expected. Please try running VisualGDB directly to get the best performance.

[support]

Hi,

The remotetimeout should not affect the initial connection problems.

Could you try locating the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\edp.xml file and increasing GDBServerDelay to 5000 or even more? Perhaps OpenOCD initialization takes longer than the 2 seconds that VisualGDB waits normally?

[support]

Hi,

Please double-check that you are using:

• The latest VisualGDB 5.2
• MSBuild subsystem
• Our original ESP32 toolchain
• The ESP-IDF that comes with our toolchain

[support]

Hi,

Thanks for confirming this. When VisualGDB displays a message about connection failure, does it offer a ‘retry’ option? If yes, does it work? If no, are you using the latest v5.2?

[support]

Hi,

Thanks for checking this, looks like the problem might be caused by the port auto-detection mechanism used by VisualGDB. Please try editing your .vgdbsettings file as follows:

    <DebugMethodID>com.sysprogs.arm.openocd</DebugMethodID>
    <DebugMethodProperties>
      <Entries>
        <...>
        <KeyValue>
          <Key>com.sysprogs.arm.openocd.gdb_port</Key>
          <Value>1234</Value>
        </KeyValue>
      </Entries>

This should force VisualGDB to use the port 1234 for connection between OpenOCD and gdb. If this solves the problem, please check if port 49321  would also work when specified manually. If yes, it can be some weird conflict between VisualGDB opening and immediately closing the port to test it and OpenOCD using it to accept connections. If you can confirm this, we will add a workaround to our OpenOCD package.

[support]

Hi,

Sorry, VisualGDB does not support this scenario as it is already supported by CMake itself. You can generate a Win32 Visual Studio project from Cmake by running cmake -G “Visual Studio <VERSION>” or you could use new CMake support from VS2017.

[support]

Hi,

Thanks for checking this. Both OpenOCD and gdb settings look correct, so it looks like some system component is preventing them from being connected. Normally OpenOCD should connect to the hardware and open a TCP port (49321 based on your log) allowing gdb to connect to it and get access to the hardware. However, despite the correct setting and matching ports, something is interfering with the connection.

To diagnose this further, please try running the OpenOCD command shown in the log from the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\share\openocd\scripts directory. Once OpenOCD is running, start a new instance of arm-eabi-gdb.exe and type “target remote :49321” there.

If the problem reproduces, please try pinpointing it via the following steps:

1. Instead of launching arm-eabi-gdb.exe and typing “target remote :49321”, please try running “telnet localhost 49321” (you may need to install telnet via Add/Remove Programs -> Windows Components). If this works, please try a different gdb binary.
2. Alternatively please try changing the port to something below 10000 (e.g. 1234 instead of 49321).
3. If none of the steps above help, please launch OpenOCD so that it opens the port 49321 and then run “netstat -a -b -n > list.txt” from an elevated command prompt and see if the output mentions OpenOCD listening on port 49321.

[support]

Hi,

Looks like a firewall or antivirus might be blocking the connection between gdb and OpenOCD.

Please try disabling it. If it does not help, please enable the diagnostic logging via View->Other Windows->VisualGDB Diagnostics Console and check if the gdb_port specified in OpenOCD command line matches the port used in the ‘target remote’ command.

[support]

Hi,

Currently the ESP32 gdb stub does not support live debugging, so you would not be able to debug your code without JTAG. If you don’t need debugging, you can create a regular ESP32 project with VisualGDB and then simply program it with the esptool.py.

[support]

Hi,

VisualGDB does not directly support libopencm3 due to its relatively low popularity. Our best advice would be to manually figure out the necessary include directories and other settings and create a project template like described in this tutorial: http://visualgdb.com/tutorials/arm/templates/

[support]

Hi,

Are you using the latest STM32 package (should be version 4.0 under Tools->VisualGDB Package Manager)? It should contain register definitions for ARM Cortex registers.

[support]

Hi,

Sorry, if the normal VS functionality is broken as well, there is not much help we could offer. You could try filing a bugreport on the Visual Studio Connect website or simply reinstalling your entire system.

[support]

Hi,

Good to know it works. BTW, VisualGDB should normally recognize and display the ‘multiple definition’ errors properly. If you believe this does not happen and those errors are only visible in the Output window, please feel free to post the Output window contents here and we will update our message parser to display them properly.

[support]

Hi,

Sorry about that. Normally the .o0 file (note the zero at the end) should contain the .data section, and the normal .o file should have it renamed according to the file properties. Anyway, if you decide to get back to this, let us know and we will gladly provide further help.

Regarding the documentation, we keep it online mostly for simplicity so that we could easily update it (e.g. use tags to group relevant tutorials) without rebuilding a huge collection of PDF files. You can easily search through all the documentation on our website by using the “site:” suffix on Google, e.g. https://www.google.com/search?q=bootloader%3A+site%3Avisualgdb.com

If this is not convenient, let us know why and we will look into making search more transparent.

[Author]

Posts