[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.

[support]

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.

[support]

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.

[support]

Hi,

You can find it on this page: https://visualgdb.com/history/

[support]

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/

[support]

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.

[support]

Hi,

Sure, feel free to renew, and we will rebuild the Renesas BSP based on the latest packs.

[support]

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?

[Author]

Posts