[support]

Hi,

The memory layout and sizes are derived from the original linker scripts in ESP-IDF that reflect the maximum supported values. The actual number of bytes used by the data or code is computed directly from the ELF file and should be correct regardless of the maximum values. Either way, you can adjust the memory layouts for all supported devices by editing the <sysgcc>\esp32\esp32-bsp\BSP.xml file (see the SupportedMCUs/MCU/MemoryMap elements).

[support]

Thanks for checking it. VisualGDB simply opens the TCP listener at the first available port, and then tells the WSL launcher to connect to it. You can try testing it out with the following C# code on the Windows side:

TcpListener listener = new TcpListener(0);
listener.Start();
int tcpPort = (listener.LocalEndpoint as System.Net.IPEndPoint).Port;
listener.AcceptSocket();

If you cannot telnet to the port reported by IPEndPoint from WSL, please try finding out which ports work, and looking for settings that could be affecting the broken port ranges.

[support]

Hi,

Please note that we are not the vendor for the ESP8266 chip.

If you have questions about the ESP8266, please consider contacting Espressif directly.

[support]

Thanks for the clarification. We have managed to reproduce the behavior – indeed VisualGDB was ignoring the “build” flag in Solution Explorer when enumerating test projects.

We have fixed it in the following build: VisualGDB-5.6.105.4604.msi. Please note that if you change the build flags while the solution is open, you would need to reopen it or close and reopen the Test Explorer window in order for the changes to take effect.

[support]

Good to know it works with ST-Link.

J-Link is generally better than OpenOCD out-of-the-box (with its own software), but the FLASH plugin interface is indeed specific to OpenOCD.

OpenOCD support for J-Link devices uses a separate open-source implementation that might contain its own bugs. If switching to ST-Link solves the problem, it could be a reasonable workaround.

[support]

If the image produced by VisualGDB is not working, while the same project built with MCUXpresso works with the same uploading/debugging method, most likely the two projects are using different memory layout. VisualGDB imports the default settings from the MCUXpresso SDK, and the SDKs generated for the MCUXpresso IDE and generic GCC (used by VisualGDB) could be slightly different.

As suggested in our first reply, you can try using the objdump tool to dump the layouts of both projects into text files, and compare the addresses of the critical parts (vector table, stack pointer, initialization code, etc.). If they are different, please double-check the linker scripts used by both versions of the project and make sure they are consistent with each other.

Ultimately, both MCUXpresso and VisualGDB use the same GCC compiler, so if the executables produced by them are different, some arguments to the compiler do not match between the 2 setups. Running objdump could help track it down, and you can also try running the command lines from both sides manually as shown in this tutorial (it is about Keil, but the VisualGDB-side steps for the GCC compiler will be similar).

[support]

This looks like you have configured some extra settings in the project to incompatible values.

Please try reproducing the problem on a project created from scratch. If the problem persists, please let us know the steps to reproduce it per our problem reporting guidelines. If the newly created project works, please try comparing its settings against the current project settings and make sure they match.

[support]

Hi,

You can find the logic used by OpenOCD to load and run the plugin in this file: https://github.com/sysprogs/openocd/blob/master/src/flash/FLASHPlugin.c.

You should be able to understand what is going on by building a debug version of OpenOCD and running it under debugger (see this tutorial).

[support]

You can work around it by creating an empty .c file and referencing it from the targets that would otherwise have no sources. Another solution would be to patch CMake to make it report interface libraries together with the object libraries, but that could be rather complicated.

[support]

Hi,

The exact location of the setting depends on your project type. Please see this page for more details. You can also double-check whether the option gets actually passed to the compiler by enabling verbose build (see project type-specific pages linked above) and rechecking the GCC command lines.

[support]

Hi,

Normally, WSL2 should work out-of-the-box, as long as the Linux side can connect to the Windows side via TCP/IP. Please see this page for a detailed instructions on troubleshooting WSL2 issues.

[support]

Hi,

You are likely missing the “init” command. In general, we would advise first running OpenOCD using exactly the same command line VisualGDB uses, then connecting to the telnet_port via telnet and running the “mdw” command via it. This should produce results consistent with regular debug sessions.

[support]

Hi,

This is a known limitation of CMake. It indeed does not report the contents of interface targets via the mechanism used by VisualGDB.

Please consider using object libraries instead – they work similar to interface targets, but their contents is actually shown.

[support]

Hi,

VisualGDB has its own easy and intuitive mechanism for custom steps. You can use the “Custom build steps” page of VisualGDB Project Properties to define a variety of different steps using convenient GUI.

Note that this feature is available starting from the Custom edition.

[support]

Good to know you managed to reproduce it. One thing, issues like this could be caused by bugs in the network stack (packet with the command from VisualGDB gets lost and is never resent). If the issue happens intermittently over SSH, but never locally (e.g. in an xterm window), it could be caused by the network rather than the gdb executable.

[Author]

Posts