[support]

Hi,

This looks like your toolchain might be corrupt. Please try using a clean toolchain and a matching SD card image asd shown on https://gnutoolchains.com/raspberry/. If it doesn’t help, please try dumping the configuration and build commands to batch files and running them manually as  shown here: https://visualgdb.com/documentation/projects/cmake/#troubleshooting

If building the project manually doesn’t work either, please double-check your antivirus. It might be preventing parts of the toolchain from starting properly.

[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. See this page for more information and detailed examples.
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.

Another common cause of errors is updating to a new toolchain/BSP/SDK. Many of these components are maintained by device vendors or communities, and require minor adjustments to the project when switching to newer versions. If you have recently updated any of such components, please consider reverting back to the old version as described here. There is no need to downgrade VisualGDB itself, as it is updated separately from such components.

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]

Hi,

Most likely, you ended up updating some of the components (e.g. BSP or some libraries to versions  that  are not 100% backward-compatible, and  then tried to troubleshoot it by changing some setting that ended up breaking the project.

Unfortunately, the issues you are describing do not look like a known issue, so our best advice would be to revert everything to the latest version that worked.

If you can point a specific setting or update that breaks the project, we can gladly investigate it further.

[support]

Hi,

Sure, VisualGDB expands the Windows environment variables the same way it does for internal variables like $(ProjectDir). So you could update your Jenkins script to set a variable (e.g. BuildNumber) and then use $(BuildNumber) in the remote directory path in VisualGDB Project Properties.

[support]

OK, we have reviewed the patches and integrated them into our repository. Thanks again for the pull request.

We have also updated the BSP generator to handle the latest SDKs and are working on an updated BSP.

You can download a preview of the BSP with the latest SDKs here, or simply wait until the next week when we finish running all tests on it and release it officially.

[support]

We agree, however re-writing everything from scratch and maintaining 2 separate copies of every feature would be an overkill for us.

That said, there has been some progress for running .Net apps on MacOS, and a few cross-platform GUI libraries are appearing, so we might be able to release some subset of the functionality on MacOS sooner or later (although we don’t have any specific plans yet).

[support]

Hi,

The Folder View is implemented by Visual Studio itself and not VisualGDB. Hence, the advanced VisualGDB functionality (Advanced IntelliSense, non-intrusive debugging, custom steps/configurations) indeed won’t work in it.

[support]

Hi,

We normally advise using the latest Visual Studio (2022), although most VisualGDB functionality works the same with all supported VS versions.

[support]

OK, we have updated both the regular OpenOCD and the ST fork. It should now be equivalent to the version used by STM32CubeIDE.

You can update conveniently via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

OK, we have just released an updated ESP32 toolchain that includes ESP-IDF 5.1 and fully supports ESP32-C6. Feel free to update to it via VisualGDB Package Manager.

We have also published a tutorial on debugging the ESP32-C6 here: https://visualgdb.com/tutorials/esp32/esp32-c6/

[support]

Hi,

It looks like the error is caused by the differences in the way gcc and clang handle the __VA_OPT__ syntax. ESP-IDF code was never tested with Clang, so it makes sense that it would trigger unexpected errors.

You can work around it by patching the definition of ESP_LOG_LEVEL_LOCAL() in esp_log.h as follows:

#ifdef __SYSPROGS_CODESENSE__
#define ESP_LOG_LEVEL_LOCAL(level, tag, format, ...)
#else
#define ESP_LOG_LEVEL_LOCAL(level, tag, format, ...) do {               \
        if ( LOG_LOCAL_LEVEL >= level ) ESP_LOG_LEVEL(level, tag, format, ##__VA_ARGS__); \
    } while(0)
#endif

The __SYSPROGS_CODESENSE__ macro is only defined by Clang IntelliSense, so it won’t affect the actual build, but will prevent IntelliSense from trying to parse unsupported syntax.

 

[support]

Hi,

Most likely the Clang cache got corrupt. Please try closing the solution and deleting the CodeDB subdirectory (normally inside the .visualgdb subdirectory).

[support]

Hi,

Thanks, this looks great! Our parser indeed only handles about 90% of the registers that are defined in a consistent way (getting it to 100% would require exponentially increasing amount of workarounds and special cases). However, this looks like a solid fix that covers several registers at once.

We will review the patches this week and will post an update here once done.

[support]

Hi,

Thanks for the update. Looks like we actually found the issue. The path from the Windows file properties is identical to the one shown in the error message, however because you are using the Parallel Studio compiler instead of GCC, it outputs the error messages in a slightly different format. So, VisualGDB ends up treating the line number as part of the path (Test.cpp(9) instead of just Test.cpp).

You can fix it by manually setting the GCC/DetailedMessage element in the <VisualGDB Directory>\Rules\RegularExpressions.xml file to:

^([^:]+|[a-zA-Z]:[^:]+|[a-zA-Z]:/[^:]+)\(([0-9]+|)(, [0-9]+|)\): (error|fatal error|internal compiler error|warning|note|Error) *:(.*)$

If the regex doesn’t cover some other messages, you can use debuggex.com to quickly test it out and tweak the regex to cover all cases.

Note that this will affect all projects and will stop VisualGDB from parsing the GCC messages correctly. If you would like to change it only for one project, you can use this build [VisualGDB-6.0.1.4882.msi] and save the attached BuildMessageRegexes.xml file to the project directory and add the following element into the .vgdbsettings files directly under VisualGDBProjectSettings2:

<BuildMessageTemplateFile>BuildMessageRegexes.xml</BuildMessageTemplateFile>

This will override the DetailedMessage element only for the projects with edited .vgdbsettings files, while using the regular regexes for all other projects (note that most project types use separate .vgdbsettings files for Debug/Release configurations and also libraries use separate .vgdbsettings files from executables).

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem, please find the answers below:

1. The delays caused by -stack-list-frames and known workarounds are described on this page. You can also open it by clicking “read more about unresponsive GDB commands” link in the timeout window shown on the screenshot.
2. The CPFver5_vgdb_LOCATION variable is set automatically based on the PATH argument passed to register_imported_project(). If you would like to update the relative path to the imported project, please consider editing the statement accordingly.

Also, the easiest way to make the imported project reusable is to create the initial VisualGDB project already in the imported project directory. You can do it using the checkboxes shown below:

Attachments:

You must be logged in to view attached files.

[Author]

Posts