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

[support]

Hi,

Strange. We tried the example above and ESP-IDF failed to parse it (100000 and 180000 are valid decimal values as well, but 1FFE000 caused it to crash). If it doesn’t fail in your msys32 environment, please double-check that you are using the same versions of ESP-IDF (perhaps it has already been fixed in the master branch of ESP-IDF).

[support]

Hi,

Thanks for the detailed description. We are planning to support the display of the function definition (not just declaration) in the popup hints in one of the next VisualGDB releases (currently you can view the declaration, call graph, references and code/data relations). We will post an update here once this is supported.

[support]

Hi,

Thanks for the very detailed description. We have rechecked this and it indeed looks like the logic for handling the ranges for hex entries still expects decimal values.

This is logic, however, is a part of the ESP-IDF itself and is unfortunately outside of VisualGDB’s control. Please consider submitting a bugreport in the ESP-IDF bugtracker for this.

The range checking is indeed not yet supported by VisualGDB, sorry. We will try to add it in one of the next releases, although we have a few other features queued (e.g. ESP32 unit test integration) ahead of that.

[support]

Hi,

Thanks for the email address update. We have linked the new email address to your forum profile.

Regarding the problem, is looks like you are missing the “0x” prefix (e.g. see how PARTITION_TABLE_OFFSET is defined in esp-idf\v3.1\components\partition_table\Kconfig.projbuild).

[Author]

Posts