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

[support]

Hi,

Sorry for the delay. We have discovered an unrelated problem while investigating this, however it should not trigger for MSBuild-based projects.

We have rechecked the sample and applied the following workarounds:

• Manually defined sram_layout and VECT_TAB_SRAM (will be fixed in the upcoming BSP update)
• Replaced SCB_VTOR assignment as follows:

 SCB->VTOR = RAMDTCM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */

The sample did run correctly after those fixes. If it doesn’t work on your side, please attach an archive with your project (clean the project and remove the .vs folder before archiving) and we can compare it with the project on our side to see what could be causing this.

 

[support]

Hi,

Sorry about that, looks like a bug introduced by a recent refactoring. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2407.msi

[support]

Hi,

It looks like some sort of a communication issue between your Linux host and the Windows host.

Please ensure that you can ping the Windows host from the Linux host and that you can connect to port 139. If not, please double-check your firewall settings.

[support]

Hi,

Yes, if you already have a tool that connects to the Segger’s telnet port and accepts TCP connections on another port, simply add its invocation to VisualGDB Project Properties -> Custom Debug Steps and then configure raw terminal to open on localhost:<port used by the tool>.

Another option would be to modify the tool to print decoded output to stdout and simply use Custom Debug Steps -> Remote Console -> Use the following command.

[support]

Hi,

Our newlib-nano build (gcc-arm-none-eabi-6-2017-q2-update) is configured with the following flags:

../newlib/configure --target=arm-eabi --prefix=/q/gnu/newlib-nano/newlib-nano-install --disable-newlib-supplied-syscalls --enable-newlib-reent-small --disable-newlib-fvwrite-in-streamio --disable-newlib-fseek-optimization --disable-newlib-wide-orient --enable-newlib-nano-malloc --disable-newlib-unbuf-stream-opt --enable-lite-exit --enable-newlib-global-atexit --disable-nls --enable-newlib-nano-formatted-io

The configuration process creates many header files with generated flags, so it’s hard to give a definitive answer. If you would like to look deeper into it, please consider building it from sources on your side and verify which version of the code is built by injecting #error directives into the source files.

Another (easier) option would be to try setting breakpoints in other functions that should be called (see the call stack below) until you pinpoint the one that is not called:

> _read() C++ (gdb)
 _read_r() C++ (gdb)
 __sread() C++ (gdb)
 __srefill_r() C++ (gdb)
 __svfscanf_r() C++ (gdb)
 scanf() C++ (gdb)

Here’s the program we tested it with:

extern "C" int _read()
{
 asm("bkpt 255");
}

int main(void)
{
 int x;
 scanf("%x", &x);
}

[support]

Hi,

Thanks for the component.mk file. Please also let us know the full path of a header file that is not shown and share the entire output from the VisualGDB Diagnostics Console.

[support]

Hi,

No worries. This is actually a known issue of gcc (e.g. see this discussion). Generally, though, we advise avoiding non-static inline functions, as they could cause hard-to-diagnose problems in large projects where multiple source files define different versions of an inline function with the same name.

E.g. if file1.cpp defines inline void memset32(void *, int, int numberOfWords) and file2.cpp defines inline void memset32(void *, int, int numberOfBytes), the debug build (with inlining disabled) may silently replace one of the implementations with another one, as both functions will get compiled as weak global symbols. Declaring inline functions as static limits them to the declaring translation unit, fully avoiding this issue and also resolving the problem you encountered.

[Author]

Posts