[support]

This could be a bug with the VS cache then.

You can try uninstalling VisualGDB, uninstalling VS2026, completely removing VS2026 directory, reinstalling VS2026, and reinstalling VisualGDB. This should fully reset all caches.

[support]

Hi,

If About VisualGDB command appears in both VS instances, the wizards should work as well.

You can double-check it by explicitly searching for “VisualGDB” in the wizard window, or using the separate File->New->VisualGDB Project command that just shows the wizards provided by VisualGDB.

[support]

Hi,

Please try completely  uninstalling VisualGDB, and then installing it back.

You can double-check the Help->About VisualGDB in both VS instances. If it is present, VisualGDB has been loaded successfully.

[support]

Hi,

We do not have that many Vitis users, so this is currently towards the end of the queue, after better STM32CubeMX integration and Renesas device support. If your company holds VisualGDB licenses, or your team is considering VisualGDB for the next project, feel free to reach out to our sales from your company email address, and we might be able to get it working faster.

[support]

https://visualgdb.com/documentation/falsepositives/

[support]

Hi,

OK, we have reproduced the issue. Switching the IntelliSense engine from MSVC to Clang involves re-creating a few relatively complex structures required for backward compatibility. It looks like something about the order in which they are re-registered interferes with filtering of keystrokes.

You can try a couple of workarounds:

• Try changing the suggestion list GUI via Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Smart Suggestion List GUI. Simpler GUI modes do not depend on the advanced filtering.
• Re-opening the file (or the entire solution) will automatically do a clean reset of the keystroke filters, so you don’t need to restart VS entirely.

That said, switching between Clang IntelliSense and MSVC IntelliSense is mostly intended for diagnostic purposes, and is expected to be done infrequently. Is there any reason you are often switching back and forth between them? We are working on a few optimizations related to caching of the sources and the Go-to-Definition command, so if you are switching away from Clang to work around issues with these commands, we might have a better fix for you.

[support]

Hi,

This looks like a broken installation. Please try uninstalling VisualGDB and installing the latest version again.

[support]

Hi,

This error means that the toolchain depends on some Python packages that have been discontinued. As a workaround, Python tries to build them from sources, and that doesn’t work due to some reason. Perhaps it needs additional dependencies, perhaps the package was never meant to be built on Windows. We don’t have any additional insights into this particular package.

We understand your frustration, but this is really not up to VisualGDB. VisualGDB can run “pip install” to install the dependencies, but if the dependencies have been discontinued by their maintainers, VisualGDB cannot automatically make them appear in the repository.

This is the main reason why VisualGDB, and its CMake framework (e.g. used for STM32) is built without Python packages and does not depend on any downloadable dependencies. However, we cannot make every hardware vendor do the same. Espressif did switch to somewhat better layout with virtual environments and newer Python versions, but ESP-IDF 5.1 is an old discontinued release. It might be just dead in the water  at this point.

Our best advice would be to find the oldest ESP-IDF version that still works, and try upgrading the project to it. If you want to keep using it beyond the end-of-life date, please consider making a VM with all the necessary tools to avoid disruptions like this.

[support]

OK, we got it working: VisualGDB-6.2.0.5606.msi

You can now create projects using the Renesas Smart Configurators by selecting “Smart Configurators” in the Embedded Project Wizard:

You can use 2 layouts:

• Without Sysprogs Embedded Framework, it will fully match the VS Code layout (device settings + project settings all defined together). The project will be 100% interoperable with VS Code.
• With Sysprogs Embedded Framework, the main CMakeLists.txt will look much smaller, and will support multiple executables (e.g. main + unit test + static libraries). But, using it without VisualGDB would require manually deploying our embedded framework.

You can also switch a project from the compatible layout to the Sysprogs Embedded Framework via context menu:

For both options, you can launch the Renesas configurator via VisualGDB Project Properties.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This still looks like some Python package issues. According to Espressif, ESP-IDF 5.1 reached the end of life last December, so they could have taken down some packages.

You can try doing a clean test by deleting the C:/Users/Beheerder/esp-idf and C:/Users/Beheerder/.espressif directories, downloading that ESP-IDF version again using the consolidated GUI, and creating a new project from scratch.

If that doesn’t work either, you can try creating a project using the Espressif’s VS Code extension. If that one fails with the same error, you would need to check with Espressif regarding workarounds.

[support]

Hi,

This looks like some Python dependencies are broken. If you are using an old ESP-IDF and old Python, the packages it requires may not be available anymore. You can try still selecting this ESP-IDF version in the new consolidated mode. It will use the Python package shipped by Espressif, that might work better.

[support]

Hi,

Sure, normally you can just use the import mode in the Embedded Project Wizard. It will add the files from the existing folders into the project.

You might need to manually translate additional settings (e.g. include directories/preprocessor macros), as we do not have an importing plugin that would automatically extract them from an Atmel Studio project.

[support]

Thanks for renewing your license.

We have looked into the new Renesas BSP and there is a major change in it. Renesas switched from shipping pre-generated linker scripts and header files to generating them during project initialization.

We are currently looking into creating a workflow similar to the Advanced STM32CubeMX Projects, that will use the VisualGDB’s project framework on top of the Renesas low-level tools for managing the project configuration.

We will post an update here once we have a preview. As a temporary workaround, you can try creating a project with the Renesas VS Code Extension, and importing it into VisualGDB. The new advanced project workflow will use a similar approach with some additional usability layer on top of it.

[support]

Hi,

The “stack location is not writable” check simply attempts to write and read some memory just before the _estack variable. Normally, it should be writable because that’s where the initial stack goes, but in some layouts it would not make sense. E.g. if there’s a custom bootloader that uses a different memory region to enable the memory for the main stack, VisualGDB would not automatically know about it. It’s just a quick check designed to point out when you accidentally used an incompatible device.

Same for compare-sections. It merely compares the contents of the ELF file to the readout from the device. There are scenarios where they would legitimately mismatch, and other scenarios where it would indicate a problem. It’s generally up to you to study the memory layout of the device, and the boot sequence, and understand whether it indicates a problem or not.

Regarding other questions:

• We have not encountered any problems with either probe. J-Link generally works better for classic devices, but Raspberry Pi used OpenOCD for their own development, so it could work better in this case.
• booot_stage2 does not look like any VisualGDB setting. If it’s something from the Pico SDK or OpenOCD, you would need to check their documentation.
• The Memory Explorer just takes the default FLASH size from the device definition. You can override it via VisualGDB Project Properties -> Memory Layout (requires the Custom license or higher)
• The other 2 errors are not coming from VisualGDB either. You would need to check the OpenOCD sources to determine what causes them.

[support]

Hi,

No problem, please find a detailed reply below.

The mixed ${TOOLCHAIN_ROOT} vs $ENV{TOOLCHAIN_ROOT} are mostly due to historical reasons. Our BSP engine started out with just GNU Make, then got ported to then-limited CMake, and eventually evolved into the current Advanced CMake Project Subsystem. At each step we tried to maintain maximum compatibility with the previous versions, that led to some redundancies.

That said, we’ve been working a while on a streamlined cross-platform subset of our CMake subsystem (and the Clang-based code navigation), and we just got released the first version. It now expects TOOLCHAIN_ROOT to come from the environment, and sets the regular ${TOOLCHAIN_ROOT} in the generated toolchain.cmake file (see the screenshot). It also now runs natively on Windows, Linux and Mac, including the code navigation. The same update is coming to VisualGDB 6.2.

${VISUALGDB_BUILD_SYSTEM_ROOT} now also comes from ${ENV}.

The S122 case is a bug in the BSP definition. You can fix it by editing the BSP.XML file, particularly the ConditionalToolFlags elements. Make sure you delete the bsp.cmake file afterwards though, so it will be rebuilt. As Nordic has mostly moved on to the new nRFConnect framework, we do not have any plans for updating the regular SDK, but if anyone else finds this annoying, we can release a hotfix.

We fixed the debug target bug in this build: VisualGDB-6.1.103.5591.msi

We will be porting the BSP-moving GUI to CodeVROOM very soon, and will look into the bug you mentioned.

Attachments:

You must be logged in to view attached files.

[Author]

Posts