[support]

Hi,

Thanks for sharing this.

The Live Variables rely on the debug probe’s ability to provide an independent interface (completely parallel to GDB) for accessing the memory. Last time we checked, BMP did provide such an interface.

If anyone could patch the BMP sources to support a separate memory access interface, we will be happy to share instructions on creating a VisualGDB debug plugin to use it similarly to OpenOCD and J-Link.

[support]

Hi,

Sorry for the confusion. The command got renamed to Manage VisualGDB Packages as it now also handles Linux test frameworks and other non-embedded packages. Please use the new command instead.

[support]

Hi,

The GDB binary is typically supplied with your toolchain and depends on your project type. Generally, we were not able to get gdb to work reliably with spaces in paths during our tests and hence recommend using paths without spaces. You can try working around this via the Path Mappings page of VisualGDB Project Properties (see the “All Commands” view of the GDB Session window to see the exact commands sent by VisualGDB), setting the “Use file names only” checkbox on the Advanced GDB Settings page, or by running the breakpoint commands with different path syntax directly via the GDB Session window.

If you manage to find a specific breakpoint command that works with your paths, feel free to post it here and we will help you configure VisualGDB to issue this command.

[support]

Hi,

This looks like the c:/sysgcc/raspberry/bin/../arm-linux-gnueabihf/sysroot/usr/lib/arm-linux-gnueabihf/libm.so file was not synchronized properly. It could be a VisualGDB bug, or might be caused by something else.

Please try deleting all subdirectories in the toolchain’s sysroot directory except for etc, then resynchronize it again.

If the problem persists, please try checking whether libm.so file is a symlink (note the backslash instead of forward slashes):

dir c:\sysgcc\raspberry\bin\..\arm-linux-gnueabihf\sysroot\usr\lib\arm-linux-gnueabihf\libm.so

If it is a symlink, please check if the target file pointed by the symlink physically exists and contains a valid ELF signature. Please also check any warnings shown during sysroot synchronization. E.g. insufficient disk space or corrupt file system might prevent some files from being synchronized.

[support]

Hi,

Please try synchronizing the toolchain using VisualGDB 5.4 Beta 2. It includes an optimized file transfer engine that works around known problems with sysroot synchronization.

[support]

Hi,

The issue is not related to any VisualGDB settings – it is 100% between the toolchain and the target. Please let us know which toolchain and what SD card image you are using.

[support]

Hi,

Thanks for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.12.2672.msi

[support]

Hi,

Thanks for confirming your license status. We have linked your forum account to the license purchased by NHTV.

The error you are experiencing happens because your program was linked against a version of the glibc library that is incompatible with the actual library installed on the device. Please double-check that you are using a version of the cross-toolchain that is compatible with your SD card image. If you have installed any updated on your target device, please synchronize the toolchain’s sysroot with it (the new VisualGDB 5.4 Beta 2 uses a much faster mechanism for synchronizing the sysroot).

[support]

Hi,

It looks like your support period has expired. Please renew it via this page (note that the 50% renewal discount will add 1 year to the previous expiration date and not to the current date) and we will be happy to help you.

[support]

Hi,

Yes, please try installing VisualGDB 5.4 Beta 2.

[support]

Hi,

The CMake code model reporting logic is generally relatively simple and only covers a few most common parameters. We extended it a lot in our CMake fork (including the ability to step through CMake files) and we may eventually add support for reporting generic properties (or specifically resources), however currently we cannot promise any timeframe for this. Please consider creating a patch for our CMake fork that will report the necessary information (alternatively we could give you a quote for developing this as a custom feature).

[support]

Hi,

Thanks for confirming this. We will include the new device ID in the next release of our debug package for J-Link/J-Trace.

[support]

Hi,

Thanks for reporting this. The problem might be caused by the fact that VisualGDB doesn’t support ADF out-of-the-box. Please try checking if the problem persists when debugging a regular ESP-IDF project.

It also looks like your technical support period as expired. Please renew it here in order to keep on receiving technical support.

[support]

Hi,

Sorry, the ADF project structure is different from the regular ESP-IDF projects, so VisualGDB does not support it out-of-the-box.

VisualGDB supports non-CMake ESP-IDF projects by running GNU Make in the “dry run mode”, capturing the gcc command lines to BuildCommandLines.txt and then reconstructing the code model (i.e. the exact list of built files) from it. Currently, it looks like the build fails because VisualGDB doesn’t set the ADF_PATH variable expected by the Makefile (see the line mentioned in the error message). Please consider hardcoding the ADF path in the Makefile, or via Windows environment variables.

[support]

Hi,

Sorry, this still looks like a relatively rarely used feature, so we will only be able to support it if CMake itself reports the resources via the JSON code model interface.

[Author]

Posts