[support]

Hi,

Thanks for the detailed feedback. We have addressed most of the issues in this build: VisualGDB-6.0.107.5295.msi. Specifically:

1. We have added a checkbox for relocating the project file to the imported project’s directory, similar to imported STM32Cube/IAR/Keil projects. It is located under the import mode selection switches.
2. The device selection tab is needed because many parts of VisualGDB (debug engine, tracing engine, live memory engine, etc) can enable various optimizations if the device type is known. You don’t strictly need to set it and can proceed with the empty “manual” mode or pick any similar device, but you may end up needing to manually fine-tune debugging or configure other parts of VisualGDB.
3. The CMake binary is pre-loaded based on other settings from the previous page (e.g. whether you are building it remotely). We could theoretically add logic for checking whether these settings got changed after changing the CMake path, but given that the non-default paths are used rarely, going back and forth through the pages is also not very common, and the workaround is trivial, we would rather not add any additional complexity to that part.
4. There was indeed a bug with the CMake presets. Importing a preset without a build directory would show a rather generic error message, and if you configured the directory manually, it would not be applied until you reopen the project. We have fixed both issues: instead of the generic message, VisualGDB now clearly asks if you want to review/adjust the presets (where the missing value is immediately highlighted), and the changes are properly applied without having to reopen the project.

[support]

Hi,

Thanks for the screenshots. With the variable values it looks like conflict between the bootloader symbols and application symbols (both have the same variable defined at different places). We have added another step to the application tutorial showing how to avoid it by disabling bootloader symbols and debugging only the application.

The second error is caused by a workaround that is no longer required with the latest GCC. We have fixed it in our development branch, and you can apply it on your side by removing these lines from %VISUALGDB_DIR%\gcc_compat.h:

#ifdef __ARM_EABI__
#define __LDREXW(expr) *(expr)
#define __STREXW(expr, val) expr
#endif

[support]

Hi,

This probably happened because the project was created when the BSP was installed in the single version mode. Then the BSP got switched to the multi-version mode via VisualGDB Package Manager, that resulted in moving the files to the version subfolder.

If you are using GNU Make or MSBuild, the .vcxproj file has to explicitly reference the exact sources from the BSP, so you would need to update it via VisualGDB Project Properties -> Embedded Project -> Regenerate MCU Files. CMake-based projects just reference the BSP version and compute all paths dynamically, so they don’t need any changes.

[support]

Sorry, doesn’t look like any known issue. Please consider attaching a screenshot illustrating the problem along with the GDB log.

[support]

Hi,

You can try reporting it to ST. Our packages are directly based on their SDKs, so any fixes they make in the subsequent versions will be automatically included in our BSPs as well.

[support]

Hi,

OK, good news! ST has finally released the source code for the STM32H7R/S support in OpenOCD, so we merged it with our fork, enabling faster Live Memory and other features on these devices.

We have also published an updated BSP that includes the external memory manager and a few other STM32H7R/S-specific libraries as easy-to-use frameworks.

We have published a tutorial on a bootloader project and another one for the main application. Programming the latter requires installing the STM32CubeProgrammer tool, however now that OpenOCD support is properly merged, you can try creating an OpenOCD plugin for the external memory if you want to avoid external dependencies (we may eventually publish another tutorial on that, but not currently).

[support]

@arrow201,

This is caused by 2 issues with the latest ESP32 Arduino package:

• One of the zip files from the latest package uses a slightly unconventional header format that causes problems with some zip libraries. We have already patched our logic handling it and will include it in the next maintenance release. For now, you can use Arduino IDE to install the problematic packages. VisualGDB will work with them just fine.
• Another zip file has several files with very long paths (e.g. esp32\tools\esp32-arduino-libs\idf-release_v5.3-cfea4f7c-v1\esp32\include\espressif__esp_matter\connectedhomeip\connectedhomeip\src\app\clusters\boolean-state-configuration-server\boolean-state-configuration-delegate.h). Depending on where you install it, it may or may not trigger the “path too long error”. Arduino IDE uses a workaround to bypass the limit while unpacking, but if you try including these headers from your sketch, they won’t work because GCC does not bypass the limit.

Issues like this are common for Arduino packages, they are often hard to reproduce (e.g. because the path error depends on the library location, that in turn depends on your username), and are often fixed by package vendors in subsequent releases. So, whenever someone runs into issues with Arduino, ESP32, or any other framework not maintained by us, we ask for 2 things:

1. To make sure that the project works outside VisualGDB. E.g. if you try including boolean-state-configuration-delegate.h from your sketch, it won’t work with the Arduino IDE and it won’t work with VisualGDB either.
   
2. If the project works outside VisualGDB, we ask for a license with an active technical support because if we do end up adding a workaround, we won’t be backporting the fix to older VisualGDB versions that were released before the package in question.

When you reported in the other thread that installing the package with Arudino IDE works, we rechecked the installation logic and patched the zip extractor, but in many other cases the Arduino IDE would show exactly the same error, and there won’t be anything to patch on the VisualGDB side.

[support]

Thanks for letting us know. We will keep an eye on it and will consider investigating it if other users with active licenses confirm the issue.

[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[support]

Does the STM32WB55 tracing work with Segger Ozone? If yes, please attach a screenshot of the functionality you are looking for, and we will advise whether VisualGDB supports it.

[support]

Hi,

The hardware ARM tracing requires more pins than just traceclk/traceswo. Generally, the J-Trace documentation should explain all the necessary wiring and you can verify that it is working with the Segger Studio.

For VisualGDB integration, you can check this tutorial: https://visualgdb.com/tutorials/arm/tracing/traceback/

[support]

Good to know it works.

VisualGDB’s Arduino subsystem is specifically designed to replicate the original Arduino build process. It plugs into the Arduino builder to extract the compiler flags into IntelliSense, but otherwise it uses the same paths, same tools, and same build rules to produce exactly the same build result as the original IDE (but with much better GUI, IntelliSense and debugger integration).

If you had to manually specify a particular package list URL in Arduino IDE, it could have installed different (patched?) versions of the packages compared to what VisualGDB installed. You could have achieved the same result by changing the board URL in VisualGDB’s Arduino settings. Either way, it’s fairly typical for Arduino ecosystem to have multiple slightly different versions of packages that need some manual installation/configuration. But once you get it working to the point where Arduino IDE works, VisualGDB will pick up your configuration and will produce the same results as well.

Edit: we have double-checked that package lists and it turned out VisualGDB was using an older package list URL and installing slightly older package versions (that we previously tested on our side). It is hard to say why they would cause random errors instead of just working as they used to earlier, but we have updated the package list URL on our side to match the latest URL from Espressif. Now the packages installed by VisualGDB should 100% match the ones you installed manually.

[support]

Please confirm that the same project using the same libraries works with Arduino IDE. If not, it is not a VisualGDB issue and it cannot be fixed by VisualGDB.

[support]

Hi,

Looks like the Arduino package might be broken again. You can try checking with Arduino IDE, just make sure you are using the same package versions. If it is also broken, it won’t work with VisualGDB either. If not, we can help you replicate the build results from Arduino Studio.

[support]

Hi,

You would need to run the built executable directly from the target’s terminal to see its output there. The setting controlling the output only affects the X11 window forwarding; the regular text output from the program always goes to VisualGDB when debugging it with VisualGDB.

The path on the target depends on whether you are building the code directly on target, or using a cross-compiler. The easiest way to find out is to open VisualGDB Project Properties, click the variables hyperlink in the bottom, and check the value of $(DeploymentPath) and $(TargetPath). Depending on your project configuration, one of these will contain the executable’s path on the target.

 

[Author]

Posts