Forum Replies Created
-
Posts
-
Yes, please try this tutorial. It shows the GUI from an older VisualGDB version, however is still relevant for the latest VisualGDB 5.5.
Hi,
The ESP-IDF environment is known for relatively low backward compatibility. Typically only a specific toolchain version will work with a specific ESP-IDF version, and upgrading project to a newer ESP-IDF release may often require non-trivial changes to configuration files.
You can read a detailed overview of this, and suggested troubleshooting techniques in our ESP32 documentation: https://visualgdb.com/documentation/espidf/#troubleshooting
Hi,
VisualGDB does not have any special support for Bazel, however you can certainly import the project into VisualGDB in the manual mode (VisualGDB will simply run the specified command line to build the project, but you would need to configure IntelliSense and manage Bazel build files manually).
If you encounter any issues along the way, feel free to provide more details and we will help you resolve them, however we would kindly ask you to renew your technical support here first.
Please note that VisualGDB is a productivity tool. It can simplify the workflow of a software engineer by automating various common tasks, however it cannot completely replace a software engineer with relevant experience, or automatically translate a textual problem description into a working prototype.
Our support is limited to VisualGDB issues only (i.e. when a specific part of VisualGDB is not working). Suggesting design patterns, creating reference designs and troubleshooting of projects is not covered in our regular product support.
As the issue you reported is a generic question about memory organization for a specific project, and is not specific to VisualGDB, we will not be able to provide further help with it. Please consider contacting ST support if you need further help.
Another option would be to first get it working using regular Makefiles, or any other IDE, such as STM32CubeIDE, and then we can help you import that project into VisualGDB and understand the relevant VisualGDB settings.
As we have mentioned multiple times before, the requirement for the “::” syntax for casts is a known limitation of our Natvis parser. Currently, it does not require a full C++ expression parser, so it simply wraps everything that looks like a member and passes the expression to gdb for evaluation. E.g. ((Field1) + Field2) gets translated to ((object.Field1) + object.Field2).
Properly recognizing C-style casts, such as (Type)(Field1) and translating them to (Type)(object.Field1), but not (object.Type)(object.Field1) requires much more complex logic. Because this affects a tiny fraction of our users and can be easily worked around with the “(::Type)” syntax or static_cast<>, we will not be able to redesign our parser to avoid it, unless someone is willing to directly cover the development expenses for it (that would be greater than what we charge for a few licenses).
If you have other issues you would like us to investigate, please let us know the email address associated with your license and we will look into them.
No problem, we can help you get it working with your specific project as a part of our consulting services. Please feel free to contact our sales to get a quote and we will be happy to delver a working example demonstrating the exact configuration you need.
Hi,
On the VisualGDB side, you can modify your project to use RAM1 or RAM2 as FLASH.However, you would need to take special care to ensure they are loaded properly in production environment.
We would advise first getting familiar with linker scripts, sections and attributes by following the Additional Memories and Linker Script tutorials.
Once you get a good understanding of linker scripts, you can try editing the default linker script similarly to what VisualGDB does with Additional Memories:
- Add a memory region for RAM1 or RAM2 if it’s not added already.
- Create a section that will be placed there. Make sure it’s not placed in the regular FLASH (see the Additional Memories tutorial).
- Use attributes to place parts of your program into the new section.
In the debug environment, VisualGDB will automatically load both FLASH and RAM with the correct data.
In the production environment, your Linux code would need to make sure the RAM gets initialized with the correct values before your program starts. You can dump the initial contents of the RAM section into a separate binary file by running objcopy:
arm-none-eabi-objcopy -O binary --only-section=<your section name> <ELF file built by VisualGDB> <output file>
Then, use the Linux-side API to manually load this file into RAM before turning on the Cortex-M4 core.
Hi,
This looks like a corrupt ESP32 toolchain or ESP-IDF. Please try following our ESP32 troubleshooting instructions to narrow it down.
The progress text from esptool.py often contains too long or confusing lines, so VisualGDB only shows it once you expand the view using the button to the right of the progress bar where you can see the entire context. We will try to improve it in one of the next VisualGDB versions and perhaps show a summary of the current operation.
Hi,
The scripts used by VisualGDB are taken from the original OpenOCD repository (see our fork on github) where they are contributed by ST.
As the scenario you described is relatively rare, the regular OpenOCD scripts (used by VisualGDB) likely do not support it. Once ST contributes updated scripts supporting this properly, our OpenOCD package will include them as well, and VisualGDB will support it out-of-the-box.
Until then, our best advice would be to simply copy the STM32CubeIDE script to your project directory and configure VisualGDB to use it instead of the regular script. You can tweak the OpenOCD command line used by VisualGDB via VisualGDB Project Properties -> Debug Settings -> Advanced. Use can use the $(ProjectDir.forwardslashes) variable to avoid hardcoding the absolute path to the project directory.
Hi,
The VisualGDB Android support focuses on a few very advanced scenarios needed by our enterprise users (such as unit tests, management of complex CMake-based repositories and development of low-level Android utilities). If you are new to Android and are just looking for an easy way to get a basic app working, there is no advantage of using C++ over Java, hence VisualGDB does not aim to support this scenario. Please consider using native Java-based tools instead.
Hi,
You can use the Memory Explorer window to get a detailed report on the RAM/FLASH usage by various parts of your program and then replace some of them with less memory-intense alternatives.
Hi,
Unfortunately, it’s hard to suggest anything specific based on the description you provided. Most likely, some of the project settings contains an invalid path somewhere.
If the problem occurs consistently, please share the steps to reproduce it per our problem reporting guidelines and we will look further into it.
Based on our best knowledge, the ESP8266 GDB stub is not compatible with the v3.x SDK. You can try cloning the gdb stub project explicitly and add its source files to the project. If the stub doesn’t work, please double-check with Espressif whether there is a gdb stub version compatible with the SDK version you are using.
Hi,
Both VisualGDB and STM32CubeIDE perform debugging using the open-source OpenOCD tool. OpenOCD is normally started by passing it a few initialization scripts that configure it. Once it is initialized, it begins listening for incoming connections from GDB.
If you encounter different behavior with VisualGDB vs. STM32CubeIDE, most likely, OpenOCD is launched with different parameters/scripts. If this is the case, please try extracting the OpenOCD command lines from both VisualGDB and STM32CubeMX and try running them manually. If OpenOCD behaves differently, please compare the 2 command lines and try experimenting with them to see what difference is affecting the issue.
If the OpenOCD script used by STM32CubeIDE is different from VisualGDB’s one, we would advise simply copying it to the project directory and manually overriding the OpenOCD command line in VisualGDB Project Properties -> Debug Settings to run it. If the command lines appear identical, please try checking if using the OpenOCD executable from the STM32CubeIDE instead of the VisualGDB-supplied executable changes anything.
Hi,
Thanks for the suggestion. We have updated VisualGDB to combine data from multiple live variables into the same CSV file. Please try this build: VisualGDB-5.5.104.3945.msi
