[support]

Thanks for the detailed repro steps. The issue was triggered by adding folders to first-level Solution Explorer nodes with source/header filters disabled. As it is a relatively rare scenario, it makes sense why it wasn’t caught by our tests or reported by anyone else.

We have fixed the issue in the following build (and also added a checkbox for creating an extra node for the imported folder itself): VisualGDB-5.6.104.4538.msi

[support]

Hi,

This is handled directly by CMake, rather than VisualGDB. Feel free to browse through CMake source code to see if there is a way to modify this behavior.

[support]

Hi,

Good to know it works.

Regarding the activation, you can always reenter your key via Help->About VisualGDB in order to update its state.

[support]

Thanks for the detailed repro steps. It looks like you are targeting a device from an Atmel START SDK that you have previously imported into VisualGDB. This issue could be a bug of this specific SDK, or a glitch in our importing logic.

Please try deleting the imported SDK (its location is shown at the bottom of the Device Selection page in the wizard) and importing it again. If the problem persists, please upload original SDK archive in a file sharing service and post a link here, so that we could recheck if our importing logic is handling it correctly.

[support]

Thanks for updating your profile. Unfortunately, we are not able to review specific projects for errors, however we can help you get the command dumping to work.

If you could attach a screenshot of the entire Visual Studio window showing the VisualGDB Build window with the missing commands, we can help you understand why they are missing.

[support]

Hi,

Please refer to the following page for more details: https://visualgdb.com/documentation/colors/

[support]

Hi,

No problem, we will try to help you. First of all, it looks like your support period has expired, so we would kindly ask you to renew it here.

Second of all, please try dumping the configuration and build commands to batch files as described here. Then, run them and make sure the problem persists.

Once you confirm it, please try editing them, replacing any incorrectly escaped characters. Once you can confirm that this fixes the build, please share both the original and patched batch files, and we will update VisualGDB to use the correct encoding.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

[support]

Hi,

Sorry, VisualGDB does not support the XC16 devices. They use a completely different toolchain from PIC32 that has never been tested on our side, and we are not aware of any debug stack on XC16 that would be reliably compatible with the GDB workflow.

[support]

Hi,

It is totally possible that older versions of CrossWorks would handle things differently. This is exactly why we published the sources of our importing plugin.

There is no special tutorial for the plugin, you can simply open its solution in Visual Studio, build it and replace the original plugin in the VisualGDB directory.

As for the build flags, they are likely stored in way that the importing plugin cannot easily deduce (or is different from the CrossWorks version we tested). Specifying them manually, or patching the plugin if you would like to import multiple projects, should work just fine.

[support]

Thanks for renewing your support.

Our CrossWorks project importer uses the .ind files to determine the full list of implicit sources (coming from CrossWorks packages) used to build the project. In our experiments, this was the only way to locate these implicit dependencies that are otherwise not referenced anywhere.

You can actually find the logic used by the CrossWorks importer here. We intentionally publish the sources for all project importer plugins, so that our users can tweak them to their needs.

In this case, you can simply ignore the warning about the .ind files and proceed with importing the project anyway. If the resulting project won’t build due to missing symbols, you can try examining the map file produced by CrossWorks, or searching the object files in its build directory for the definitions of these symbols, and manually adding the corresponding files to the VisualGDB project.

In general, when it comes to importing projects from other tools, VisualGDB can automatically parse common settings (list of source files, include directories, preprocessor macros, device type, etc.), but indeed, it won’t translate every possible setting from the original project file. This speeds up the importing process compared to creating a new project and adding everything there manually, but indeed requires minor adjustments to accommodate the settings that could not be translated automatically.

[support]

Hi,

This looks like something specific to your target (e.g. some headers got moved or edited).

The easiest way to fix it would be to delete the cached include directories for that target (via VisualGDB Project Properties or by deleting %LOCALAPPDATA%\VisualGDB\RemoteSourceCache\<hostname>) and rebuilding the MSBuild toolchain profile (VisualGDB Project Properties -> MSBuild -> Regenerate MSBuild Files).

If it doesn’t help, please try locating the %LOCALAPPDATA%\VisualGDB\ToolchainProfiles\<hostname>\com.sysprogs.toolchain.default-gcc-\IntelliSense.props file. It contains the include directories and preprocessor macros used to configure IntelliSense based on various options (e.g. language standard). You can simply add the /usr/include/c++/10/tr1  directory to the AdditionalIncludeDirectories element (or even make it conditional on CPPLanguageStandard, similar to PreprocessorDefinitions). Editing the file and reopening the solution will make the directory visible to IntelliSense without affecting the build.

[support]

Hi,

No problem, we will try to help. The delay could be caused by 2 independent issues:

• Reading/parsing the symbols from the ELF file
• Physically reading the memory contents from the device

It is difficult to suggest anything more specific without seeing which parts of the GUI get delayed and which modes you are using. If you could create a short video demonstrating the problem, we might be able to suggest some workarounds.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[Author]

Posts