[support]

Hi,

The “could not find file” error happens because the regular OpenOCD and the ST fork use slightly different script names. You can view the available scripts by enabling the raw view in the device selector under VisualGDB Project Properties -> Debug Settings.

If you are able to connect to the device while holding reset, please try checking the “connect under reset” checkbox in the OpenOCD settings. This way it should work similarly to your current STM32CubeProgrammer configuration.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

[support]

Hi,

There is no special option to select a particular Nucleo board on the VisualGDB side. You can try selecting a device, letting VisualGDB launch STM32CubeMX, and then checking for options to add a board.

If this doesn’t work, you can simply generate an STM32CubeIDE project (not GPDSC) and import it via the VisualGDB’s Embedded Project Wizard. It will work as good as the Advanced STM32CubeMX Project Wizard.

That said, if you are using STM32CubeMX 6.5.0, please consider updating to the recently released VisualGDB 5.6R6. It includes a workaround preventing STM32CubeMX from inserting irrelevant files into the generated project, causing the build to fail.

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

[Author]

Posts