[support]

Hi,

No problem, please let us know the email associated with your license key so that we could link it to your profile, and we will help you get it working.

[support]

If you are using the latest VisualGDB version, something is likely interfering with the VisualGDB internals. Please make sure you use an unmodified VisualGDB installation. If the problem persists, please try installing it on a different computer.

[support]

Hi,

Sorry, we have tried reproducing this on the latest VisualGDB build, but it worked just fine.

Please try updating to the latest VisualGDB 5.6 Beta 4. If the problem persists, please try changing your tab settings (e.g. tab size = 4, keep tabs) and let us know if this changes the behavior.

Also please try disabling all other VS extensions. One of them might be interfering with the VisualGDB’s code formatting logic.

[support]

Hi,

We generally prioritize feature requests based on the number of affected users. As this is a very specific request affecting a very small number of users, and can be achieved by implementing a custom visualizer, it has a very low priority and will likely not be added anytime soon.

If your company holds multiple VisualGDB licenses, please let us know the email associated with your key, and we will assign a higher priority to this.

[support]

Hi,

It looks like the .ewp file structure is slightly different from what VisualGDB expects, so the importing logic fails. If you could attach the .ewp file (please put it into a .zip archive), we can gladly investigate it and fix the importer.

If you do not wish to share the project file, you can also fork and update the IAR importing plugin directly.

The TrueStudio import should work out-of-the-box, as long as you select it in the wizard. If not, please let us know more details and we will look further into it.

[support]

Hi,

No problem. Please try uploading the zip file with the entire project to a file sharing service (e.g. OneDrive/DropBox) and posting a link here.

[support]

Hi,

We normally support the toolchains that are available as stable releases from Espressif. I.e. once a toolchain is available via the ESP-IDF tool installer, we recheck it on our side, make sure that the VisualGDB GUI is fully compatible with it, bundle it with the matching ESP-IDF version that we tested, and re-release it as a ready-to-use VisualGDB package.

Currently, the latest ESP-IDF installer (v2.10) still installs the esp-2020r3-8.4.0 toolchain, that matches our latest toolchain (esp32-gcc8.4.0-r3.exe).

Once the new toolchain is released by Espressif as a stable binary package, and is made available via the ESP-IDF installer, feel free to get back to us, and we will give you a timeframe on repackaging it as a VisualGDB package.

If you would like to experiment with pre-release versions of the toolchains, you can do it by simply building them manually and replacing the binaries inside c:\SysGCC\esp32 (the versions and paths are stored in the Toolchain.xml file), however it is something to do at your own risk.

[support]

Hi,

Thanks for sharing this. The exact FPU macros also depend on the selected CPU/FPU type, so the logic for detecting them based on the “-mfloat-abi” option alone indeed won’t be 100% accurate. That said, it only affects IntelliSense and will not cause any behavioral issues in the code. Editing the file IntelliSense.props file manually (or adding the extra IntelliSense flags options via VisualGDB Project Properties -> IntelliSense Settings) should indeed work around it.

Also, please consider switching to the new Advanced CMake Embedded Project subsystem. It uses a different mechanism for configuring IntelliSense that is not prone to this issue.

[support]

Hi,

If the issue is present with the default settings, it’s likely caused by some special characters in the source files. Please try reproducing it on a new project created from scratch, and then try attaching a .zip file with the entire project here, so that we could try reproducing it on our side.

[support]

Hi,

Our ARM toolchain is based on the same sources as the official GNUARM toolchain (specifically, the 9-2020-q2-update release). The only difference from the original toolchain is that we rebuilt it with big endian support.

Please refer to the official GNUARM documentation for specifics on supported libraries, versions and features.

P.S. We are also working on an updated toolchain build based on 10.3-2021.07, however, it is also directly based on the GNUARM toolchain sources and will work exactly the same as it.

[support]

Hi,

Unless the project contains all the necessary files so that we could build it and observe the same behavior as you have, it’s hard to suggest anything specific.

Please try updating to VisualGDB 5.6 Beta 4. If the problem persists, please try uploading the entire project to a file sharing service (e.g. Dropbox/OneDrive) and posting the link here.

[support]

Thanks for the detailed repro steps. We have tried reproducing it on our side, and got the “../” paths in the build log, however clicking on them worked as expected.

Please try updating to VisualGDB 5.6 Beta 4. If the problem  persists, please try attaching a .zip archive with the faulty project so that we could recheck it on our side.

Also, as a side note, moving the project like this would break the connection to the BSP folder, and might interfere with some of the functionality (although not the build log navigation).  A much easier way to accomplish it would be to already create a project in a subdirectory (e.g. c:\projects\name\Solution) and use “..\BSP” instead of “BSP” when converting it to a stand-alone one.

Also, please consider switching to the Advanced CMake Project Subsystem. It is designed to specifically address the shortcomings of GNU Make and MSBuild, and generally works much better, while allowing you to build the projects outside VisualGDB as well.

[support]

Hi,

Most likely, you have selected some combination of settings that breaks either the VisualGDB formatting logic, or some other extension.

First of all, please double-check that you are using the VisualGDB’s Clang IntelliSense, and also recheck whether you are using Clang-format or Sysprogs Formatting Engine as described here.

If you are using Clang-format, please share your .clang-format file so that we could recheck what is going on.

If you are using SysprogsFormat, please try resetting all VS-level settings via Tools->Import and Export Settings (you can save them beforehand). If it doesn’t help, please try renaming the HKEY_CURRENT_USER\SOFTWARE\Sysprogs\VisualGDB\Settings\CppEngine key in registry.

If this fixes the problem, please try restoring the original settings one-by-one. If you can point to a specific combination of settings that triggers this problem, we will be happy to investigate it further.

[support]

Hi,

It looks like you are using an older version of Visual Studio and VisualGDB.

Please try updating to Visual Studio 16.11.1+ and VisualGDB 5.6 Beta 4.

[support]

No problem. If the problem can be reliably reproduced on a cleanly created project, please try packing it into a .zip file and attaching it here so that we could try to reproduce it on our side.

[Author]

Posts