[support]

Hi,

Sorry for the delayed reply.

The Digi tutorial is very old and does not reflect the new simplified project wizards.

Most likely you don’t need to use the Custom wizard at all – if your toolchain consists of the regular tools like gcc, ld and make, you can simply select it in the VisualGDB project wizard and VisualGDB will setup a basic project automatically including the necessary deployment steps (see this tutorial: http://visualgdb.com/tutorials/linux/3machine/).

If you want to configure manual build steps nonetheless, you can change the build machine (where gcc and other tools are located) globally on the Project Settings page.

If you encounter any further problems, please feel free to let us know and we will help.

 

[support]

Hi,

The error message should normally contain the gcc output. Does it show any details about the problem?

If not, please try running gcc manually with the flags shown in the error message. Sometimes gcc fails to start due to missing DLL files and only shows a meaningful error message if started manually from cmd.exe or Explorer.

[support]

Hi,

Sorry about that, looks like some MSBuild-related setting is preventing the .S files from being automatically recognized. If you encounter this problem again, please let us know and we will investigate.

[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.

[Author]

Posts