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

[support]

Hi,

If the regular C++ Console project does not work, something is definitely wrong with the VS installation. If repairing it does not help, please try completely removing it and installing it again.

[support]

Hi,

This behavior is somewhat by design. The Clang IntelliSense aims for high accuracy, so it needs to fully parse the source file before it can do code suggestions. If the file was modified in the last 24 hours, VisualGDB considers it to be an actively edited file and creates a “preamble” – precompiled snapshot of the header files used by the file, so subsequent IntelliSense operations work very fast. The high CPU usage by CppEngineHost.exe is normal – this is the process that hosts the IntelliSense engine (we don’t run it inside Visual Studio so that Clang crashes would not crash Visual Studio itself).

You can see what exactly is going on via the View->Clang IntelliSense Diagnostics Console.

In our tests, the first parse usually took 3-6 seconds, but never 35-45. Could you let us know which hardware you are using? Also if your project is located on a network drive, please consider copying it locally as accessing many .h files over network will be very slow.

Another optimization tip we would give is to use precompiled headers. If VisualGDB detects that over 80% of the project files include the same header file at the beginning, it will automatically treat it as a precompiled header, greatly reducing the parse time for new files, even if your build system does not support precompiled headers and is treating it as a normal header file.

[support]

Hi,

Your device may not stop the DMA clock while the CPU is stopped in the debugger, so this could cause some buffer overruns or other similar problems. We would recommend checking the UART and DMA registers to understand what exactly happens and then checking through the device documentation for ways to pause UART/DMA during debug stops.

[support]

Hi,

The newlib-nano library does not include semihosting code by default. We normally recommend referencing the “Fast semihosting & profiler” framework to get a much faster semihosting interface that works with all types of the standard library.

[Author]

Posts