[support]

Hi,

Thanks for the log file. We have fixed the first issue in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2413.msi

The second error looks like the test process terminates unexpectedly, breaking the connection. Please try identifying a specific test that causes it and then use the “Debug Tests” instead of “Run Tests” command to try locating the code responsible for closing the process.

[support]

Hi,

This might be caused by your bootloader (or some other part of the program) modifying the FLASH memory after it is programmed.

Either way, VisualGDB uses the regular “load” command (that in turn issues vFlashWrite packets to OpenOCD). If you would like to debug the FLASH programming logic used by VisualGDB, please consider creating a debug build of OpenOCD (our OpenOCD fork includes a convenient CMake-based project wrapper, see this tutorial).

Alteratively, please try runing the “load” command manually and verifying the memory contents just after it is programmed, but before the program got a chance to run.

[support]

Hi,

Most likely your binary is missing some symbols that VisualGDB expects to find inside FreeRTOS-based programs. Please try locating the following file:

<VisualGDB directory>\RTOSProfiles\com.sysprogs.freertos\RTOS.xml

Then find the RequiredSymbols element and check that your program defines all functions mentioned in side it (e.g. using the embedded memory explorer or by viewing the map file).

[support]

Hi,

The FLASH programming logic used by VisualGDB is actually provided by Espressif (either the OpenOCD FLASH programming commands, or the esptool.py). Please check with Espressif regarding possible ways of optimizing either of those methods.

[support]

Hi,

Thanks for attaching the detailed logs. One error shown in the log files is the missing ‘xauth’ executable that would cause problems when running commands that require X11 redirection. Please try disabling X11 support for that host via Tools->VisualGDB->SSH Host Manager.

If this doesn’t help, please try this build and attach an updated log from the Test Output: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2411.msi

 

[support]

Hi,

The red underlines are normally shown when the Clang IntelliSense discovers errors in the code. Please check the Errors pane in Visual Studio for a specific list of errors. They should explain what is causing the problem (e.g. a missing header file, or an incompatible macro definition).

If you are not sure, please attach a screenshot of the entire VS window (showing the Solution Explorer, the source file with the navigation bar and the error pane) so we could check for common known issues.

[support]

Hi,

Sorry, the embedded CMake projects are currently somewhat limited compared to Make-based and MSBuild-based (recommended) projects and might result in weird bugs like the one with add_definitions(). We are working on improving this in v5.4, however currently using CMake for embedded targets requires some manual configuration.

You can enable the generation of relocation records by adding the following flag to LDFLAGS:

-Wl,-q

This should have the same effect as clicking “enable generation of relocation records” for MSBuild-based projects.

[support]

Hi,

If the log messages are exactly the same (OpenOCD doesn’t report any errors and gdb reports Remote communication error), most likely something in your system (e.g. a firewall) is preventing gdb from connecting to OpenOCD. Please try disabling the firewall to see if it solves the problem.

If not, please double-check that the port shown in the OpenOCD log matches the port shown in the gdb log. If this is the case, try connecting to the OpenOCD port manually using the telnet command.

[support]

Hi,

The test output looks OK. Please try restarting your computer and see if the problem still persists. If it does, please check the OpenOCD output from the debug session (VisualGDB should show it as a tab in the ‘debugging failed’ window). If gdb reports a failed connection to OpenOCD, the OpenOCD output should contain some kind of an error.

[support]

Hi,

It looks like gdb fails to connect to OpenOCD. Please check the OpenOCD log for details or try using the ‘test’ button in VisualGDB Project Properties -> Debug.

[support]

Hi,

The ESP32 gdb stub (component responsible for debugging via the COM port) does not come from us – it is a part of the ESP-IDF provided by Espressif. As soon as Espressif updates the stub to support fully functional debugging, we will update our tools to support it out-of-the-box. Until that is supported, please use JTAG for debugging.

If you find the message itself annoying, we can easily add a “do not show again” option.

[support]

Hi,

Normally VisualGDB will add it automatically based on your CPU core count, so no action is required.

You can also specify it manually via VisualGDB Project Properties -> ESP-IDF Project -> Additional Arguments.

[support]

Hi,

If you want to change the menuconfig values, simply use the first page of VisualGDB project properties. It contains a graphical editor for the menuconfig entries parsed from your project.

If you want to add new custom entries, simply add/edit KConfig files in your component directories (see the ESP-IDF documentation for more details on that).

[support]

Hi,

Looks like the Cygwin environment might not be compatible with the UNC paths. Please ensure both the ESP32 toolchain and your project are located on a regular drive letter-based path (e.g. x:\folder\subfolder) and are not using the UNC paths (\\server\share).

[support]

Hi,

Sorry, we are not able to create such a tool on-demand. We might be able to support ITM stream demultiplexing as a part of our Segger debug package later, however it is difficult to give any time estimates at this point.

If you could get the 3rd-party tool you mentioned to the point where it works when launched manually and accessed via telnet, we can help you integrate it into VisualGDB, but unfortunately we won’t be able to do any deeper research/customization for this.

Generally we advise using our Fast Semihosting framework instead. It is based on background memory reads, so it doesn’t stop the target; it is fully integrated with the VisualGDB GUI (including the ANSI sequences), is independent from the specific debug method and works with the regular printf() and other functions. It should be much easier than integrating external ITM stream processing tools into the VisualGDB workflow.

[Author]

Posts