Forum Replies Created
-
Posts
-
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.
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.
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.
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.
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.
Hi,
The recent ESP-IDF versions have more specific Python requirements than the older ones, so we created a separate consolidated toolchain mode that fully mirrors the setup used by the Espressif’s VS Code extension, and provides maximum compatibility.
Please consider deleting the existing toolchain/Python and creating a new project by selecting the consolidated toolchain. Once it works, you can try switching the existing project to ESP-IDF 6.0. That said, switching between ESP-IDF versions can require some adjustments to the project, so please make sure you have a good backup before you begin the conversion.
Hi,
The oldversions page shows all versions available for download, including the last one.
Either way, download page always shows the latest version, and the number is a part of the download URL.
Hi,
You can find it on this page: https://visualgdb.com/history/
Hi,
Based on the other feedback we received, it looks like the latest ESP32 OpenOCD might not be compatible with the old ESP-IDF versions.
You can easily revert to the older OpenOCD package as shown here: https://visualgdb.com/support/oldpackages/
Hi,
The RP2040/2350 support is provided by the Raspberry Pi Pico SDK. As long as you are using the version that supports your device, VisualGDB should work just fine with it.
Thanks for the trace file. The trace refers to the window that is shown when VisualGDB detects a changed SSH host key (e.g. different VM appearing under the same hostname). However, it should normally be shown in the correct GUI thread.
You can try triggering the window by editing %APPDATA%\VisualGDB\KnownHosts.xml file (change the KeyBase64 for the machine you are using). Does it always immediately result in a new trace in InvalidGUIThreadTraces? If not, is there any particular scenario to make the trace appear?
Hi,
Normally, everything should work automatically. If not, you can reach out to our support with your license key details, and we will look into it.
Hi,
It can be a glitch related to first installing an early preview of VS2026, and then upgrading it to the latest stable one. VisualGDB installer finds the latest MSBuild version with a non-empty Platforms subdirectory, and copies its platform files alongside the default platforms. This normally matches the Visual Studio’s default mechanism for finding the platform files.
It is difficult to say why it would look for the files in a different location this time, but copying/symlinking the VisualGDB platform to a different MSBuild version should work just fine.
If anyone else encounters the same problem, feel free to post here, and we will investigate it further.
Hi,
This means that the MSBuild files are missing from the VS installation. You can confirm it by trying to create a regular Win32 C++ project (non-VisualGDB) – it should be either missing, or would run into the same problem.
Installing Visual C++ project support via the VS installer should fix it. You can also use CMake-based projects instead, as they do not rely on MSBuild.
