[support]

Hi,

With the ESP32 projects, VisualGDB uses the regular ESP-IDF build commands to configure and build the project. Please try building the projects manually and compare the build command line with the one shown in the VisualGDB Build Output window.

If VisualGDB is missing some build steps, or runs some command lines incorrectly, please let us know and we will be happy to fix it.

If the ESP-ADF projects build on Linux, but don’t build with the Windows-based toolchain, it is likely a bug of the ESP-ADF itself and it should be reported to Espressif instead.

[support]

Hi,

Please try updating to VisualGDB 5.5 Preview 4. It will automatically check the BSP version when opening the project and will suggest retargeting it to the version you have installed.

That said, switching to a newer BSP always comes with a risk of minor compatibility issues. Getting the older BSP as described here could be a safer bet.

[support]

Hi,

Sorry about that, the new build of the OpenOCD package requires an updated VisualGDB debug engine. Please try this build: VisualGDB-5.5.5.3577.msi.

If it still doesn’t work, please check if the Debug->Windows->Live Watch->Globals view works (and updates the variables properly).

[support]

Hi,

VisualGDB would normally apply the regular C/C++ include directories and preprocessor macros to assembly files as well. If you want to add the include directory only to assembly files, you can instead add -I<directory> to Configuration Properties -> C/C++ -> Assembler -> Additional Assembly Flags.

If it doesn’t work, please let us know what exactly you added in the settings and whether any similar directories are listed in the VisualGDB\Debug\<assembly file>.gcc.rsp file (that should contain all command-line flags passed to the assembler).

[support]

Hi,

No problem. You can import an existing Zynq SDK into VisualGDB by following this tutorial. Once you create a basic project, you can export it into a project template for easier reuse.

We can also convert your hardware-specific BSP generated by the Zynq tools into a VisualGDB-level BSP (similar to the STM32 BSP and others) as a part of our paid BSP service. Feel free to contact our sales if you would like to get a quote on that.

You can run various scripts (and do all kinds of other custom actions) before/after build, and also at various stages of the debug process. See the Custom Build Steps and Custom Debug Steps pages of VisualGDB Project Properties for a detailed list of customization options.

Let us know if you need any further details and we will be happy to help.

[support]

Hi,

This should not be related to the protocol analyzers or specific I/O. It looks like the board never responds to the asynchronous I/O request. It could happen if the board had a pre-release version of the chip that would behave differently from the final one, or if the power/wiring was unreliable.

Does that specific board behave unreliably when trying any other firmware (e.g. STM32 samples)? Does Analyzer2Go also hang when trying to use the record mode with no input signals at all?

[support]

Hi,

The fast semihosting and using the custom FLASH drivers requires a secondary telnet connection to OpenOCD that runs in parallel with the regular GDB connection.

Normally, VisualGDB would automatically configure OpenOCD to open a telnet port, and would then connect to it. However, for remote setups this won’t work. As a workaround, please try this build: https://sysprogs.com/files/tmp/OpenOCDPackage2.dll

Then locate the PreferredTelnetPort element in the .vgdbsettings file and set it to a non-zero value (e.g. 4444). Add the following element next to it:

<TelnetHostName>[IP address of the machine actually running OpenOCD]</TelnetHostName>

Make sure that port is open in the firewall on the remote machine, so that VisualGDB can connect to it (you can recheck it with the actual telnet tool).

[support]

Thanks for clarifying this. Normally, just rebuilding the project should have helped. Most likely some dependencies between different components were not handled correctly, so the executable still ended up with the old debugging symbols.

Please consider reading our symbol troubleshooting tutorial. It explains how the debug symbols work and how to check their status.

[support]

Hi,

No problem. Please try obtaining and sharing a call stack of the hanging Visual Studio process as shown here: https://visualgdb.com/support/callstack

[support]

Hi,

This is to be expected. If you just rename the file, the debugging symbols will store the old file path, preventing the breakpoints from working. Please try building/rebuilding the project after you rename the file.

[support]

No problem, we should be able to fix it. However, if the issue only triggers with a few select files, we would need further information from you.

Please try creating a new embedded project from scratch. Then the .clang-format file in its directory and replace the contents of the main file with the minimal file contents that trigger the error when either saving or reformatting the document (via Edit->Format Document). Then please attach the entire repro project and we should be able to fix this promptly. You can alternatively send the repro project via our support form.

[support]

Hi,

Unfortunately, help on resolving issues with specific projects is outside of our support scope. However, we have a very detailed tutorial explaining the ESP-IDF components: https://visualgdb.com/tutorials/esp32/esp-idf/components/. We would advise following it so that you could get familiar with the ESP-IDF component semantics.

[support]

Hi,

Sorry, the regular VC++ projects follow the Visual Studio’s separation between source and header files.

If you would like to avoid it, please try using the Advanced CMake Project Subsystem instead. It allows a fine-grain control over grouping and filtering of sources in Solution Explorer. Also CMake-based projects can be built outside Visual Studio/VisualGDB, so you won’t lose the ability to build your project on a different machine, or on a build server.

[support]

Strange, the “value doesn’t fall in the expected range” looks like a .Net exception message, so you should normally still get a .Net assembly that triggers the exception. Can you confirm that the error message still looks the same after disabling the plugin? Does the outer VS instance show any exceptions in the “Output” window?

Please also try disabling the Clang IntelliSense as shown here and check if it solves the problem. If yes, please try enabling it back and then reformat the entire document (Edit->Advanced->Format Document). Does this trigger the problem?

[support]

Hi,

No problem, please try this build: VisualGDB-5.5.5.3574.msi

We have added an option under VS Project Properties -> C/C++ -> Advanced that allows explicitly specifying the input language for the source files instead of having it auto-detected from the extension.

[Author]

Posts