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

[support]

Hi,

Thanks for the suggestion. Based on a quick research, it looks like a iOS/MacOS-specific feature. As this is a relatively rare use case for VisualGDB, we will not be able to add it as a regular VisualGDB feature. However, if you could confirm that CMake reports the resources via the JSON code model interface (or could prepare a patch to our open-source CMake fork that will export this information via the JSON model), we should be able to modify VisualGDB to display the resources in Solution Explorer.

[support]

Hi,

Looks like your project properties still references the old device type (requiring the Segger driver). Please try reselecting the debug interface via Debug Settings (or creating a new project).

[support]

Hi,

This looks like some conflict between Gradle instances started by different programs. Do you have Android Studio running in background? If yes, please try closing it. If this solves the problem, please ensure that both VisualGDB and Android Studio use the same SDK/NDK versions and that they both run from the same user account (including the “Run as administrator” setting). This should prevent Gradle from restarting the daemon instances.

[support]

Hi,

Happy New Year!

Thanks for the update. This indeed looks different from the J-Trace PRO unit we used to do our tests. Please try adding a separate ProgrammingInterface element for the J-Trace:

		<ProgrammingInterface>
		  <ID>com.sysprogs.debug.jlink.jtrace</ID>
		  <Name>Segger J-Trace</Name>
		  <Identities>
			<UsbIdentity>
			  <VID>1366</VID>
			  <PID>0120</PID>
			</UsbIdentity>
		</ProgrammingInterface>

This will let VisualGDB use the existing USB driver instead of trying to install the regular Segger driver.

[support]

Hi,

No problem. VisualGDB uses its own CodeLens mechanism (called CodeJumps) that can be enabled/disabled separately. Please use the tag icon in the upper right corner of the edited source file in order to disable it (or click the ‘settings’ button in any CodeJumps popup to customize the cases where CodeJumps popups are shown).

[support]

Hi,

Sorry, this behavior has always been in place the GDB Session window is internally used by VisualGDB’s logic to display the status of various operations and will be created when starting the debug session if you closed it. As a workaround, please simply keep it in the background. As long as the “don’t activate the gdb session window” flag is set, the window will stay in the background and won’t interfere with your debug workflow.

[support]

Hi,

Sorry, the atoi() function is indeed not a part of VisualGDB. Please consider submitting a bug report to the bugtracker of the C library you are using.

[Author]

Posts