[support]

Hi,

This is by design unless you built OpenCV from sources yourself (or manually downloaded/installed debug symbols if your distro ships them). We would recommend building OpenCV from scratch (e.g. by following this tutorial). The new CMake Project Subsystem in VisualGDB 5.3 should make it much simpler as well.

[support]

Hi,

Yes, the problem occurred because our register parsing was confusing offsets and absolute addresses. We have fixed that.

The window bug should be fixed in v5.3 Preview 2 (or you can simply restart VS and run the update again).

[support]

Hi,

Thanks for reporting this, looks like our bug. We have fixed it and released an update to the Tiva package.

Please update via Tools->Manage VisualGDB Packages.

[support]

Hi,

The Clang engine is designed to only work with VisualGDB projects, so the easiest workaround would be to create a new project configuration that will be recognized as a VisualGDB-based configuration. Please try importing your project into another GNU Make-based project (not MSBuild-based) and check the VS project properties. The configuration type will be set to “Makefile” and the “NMake Output” will point to a .vgdbsettings file containing various project-specific settings. Please copy that file to your main project directory and create another Makefile configuration using the VS configuration manager. Ensure its output points to the .vgdbsettings file, the include directories are correct and the “forced include files” contain the gcc_<config>.h file with built-in macros dumped from gcc.

As long as these criteria are met, the Clang IntelliSense will recognize this configuration as a VisualGDB-based configuration and will handle the project as usual.

[support]

Hi,

The breakpoint issue could be caused by your code reassigning JTAG pins as regular GPIO (or otherwise tampering with the on-chip debug unit). Please try pinpointing the exact place in your program flow after which the breakpoints stop working.

The link error looks like it’s caused by switching the toolchain to a different version. Please try checking/unchecking the “reduce size of C++ binaries” checkbox on the first page of VisualGDB Project Properties. This should regenerate the necessary settings and fix the problem.

[support]

Hi,

With the new system there won’t be any path stored inside the .vxcproj file at all. Instead it will store the BSP ID and version and use the $(BSP_ROOT) syntax. When opening the project file with VisualGDB, it will automatically locate the BSP based on the ID and version and provide the $(BSP_ROOT) variable to Visual Studio so that VS can find the source files on your machine.

[support]

This could happen if some of your file paths contained spaces. Please double-check that the toolchain, project and the code generated by STM32Cube does not reside in paths with spaces (or switch to the MSBuild system that supports paths with spaces since VisualGDB 5.3).

[support]

Hi,

Please try rebuilding the project. The .bin file should be generated in the same directory as the regular ELF file (with no extension).

If nothing helps, please try enabling diagnostic MSBuild output via Tools->Options->Projects and Solutions -> Build and Run and check for the details on the “GenerateBinFile” target.

[support]

Hi,

Please double-check that you have X11 installed on Raspberry Pi. Does running other programs (like xterm) over SmarTTY work?

[support]

Hi,

Yes, the embedded RTOS plugins require the Custom edition or higher. Starting with v5.2 the plugin is shipped with VisualGDB and can recognize FreeRTOS-based projects automatically from looking at the symbols, so as long as you are using the correct edition, no manual configuration is needed anymore.

[support]

Hi,

The “Error: JTAG scan chain interrogation failed: all zeroes” error almost always means wiring issues. Please double-check your connection, ensure no other peripherals share the JTAG lines. If nothing helps, please try using a logic analyzer to see if there is any JTAG activity on the corresponding pins.

[support]

Hi,

It should be on the Debug Settings page of VisualGDB Project Properties. If not, please attach a screenshot of this page (we have recently added attaching functionality to the forum) and we will advise.

[support]

Hi,

The Program Files directory is normally not writable (unless you launch VS as Administrator which is often not the case), so we store the downloaded files under $(LOCALAPPDATA).

We intentionally don’t pre-install ALL of the BSPs with VisualGDB as they often get updated and none of our users will probably need ALL of the BSPs for ALL supported platforms at the same time.

The STM32 BSP is indeed huge, but as the modern HDDs/SSDs are huge as well and the scenario of one computer/multiple users is relatively rare, we don’t want to change the current layout. As a possible quick workaround we could recommend creating symbolic links between the BSP directory under %LOCALAPPDATA%\VisualGDB and a shared BSP location outside the users’ appdata directories.

BTW, we are currently experimenting with storing $(BSP_ROOT) paths in the .vcxproj files instead of the relative paths to relocated BSPs and are planning to include this in the upcoming Preview 3 of v5.3. This should solve the problem you mentioned.

[support]

Hi,

Normally, checking the VisualGDB Diagnostics Console for the exact list of commands executed by VisualGDB adn re-running them manually should explain what is going on. Most likely some of the system tools (like gdbserver) got corrupt and resulted in invoking ld.so instead.

[support]

Hi,

This could be related to a recently fixed bug in the 64-bit engine. Please try downloading this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.2.1620.msi

If the crashes still happen, please try deleting the CodeDB directory and reopening the solution.

[Author]

Posts