Forum Replies Created
-
Posts
-
Hi,
In the latest VisualGDB 5.5R4 multiple output windows have been merged in a single VisualGDB Output window (item #7 on the screenshot).
This was done because previously different output windows (e.g. semihosting or gdbserver output) would appear dynamically in front of other windows, depending on the actual output of the underlying program. Now the combined VisualGDB Output window is always shown during debug sessions and will always remember the state/location it had at the end of the previous session.
You can revert back to the old behavior using the Use Combined Output Window setting.
Hi,
Please try using the Signals button in the GDB Session window.
Hi,
Normally you should be able to open the semihosting window via a command under the Debug->Windows menu. If it doesn’t work, please try reproducing the problem on a clean project created from scratch.
If the problem persists, please let us know the steps we could follow to reproduce it and we will investigate it further.
Hi,
VisualGDB fully supports Segger J-Link via the Segger GDB stub, however we have not specifically tested it with the multi-core STM32H7 devices.
Generally, we would advise simply using ST-Link as shown in this tutorial. It involves a special build of OpenOCD maintained by ST that has been specifically designed to work with the multi-core devices. If you would like to double-check whether J-Link supports this configuration, please contact Segger support. If they can confirm that the Segger GDB stub supports the device you are targeting, VisualGDB will work with it out-of-the-box.
Hi,
The temporary builds get automatically cleant up after some time, so you indeed got the latest build instead. Please try updating once again to this one: VisualGDB-5.5.104.3973.msi
If the problem persists, please try enabling the View->Other Windows->VisualGDB Diagnostics Console and reproducing the problem. Once the problem is reproduced, please attach the contents of the diagnostics console here along with a screenshot of the Help->About VisualGDB window.
Good to know it works. BTW, if you are not using the new Advanced CMake Embedded Project Subsystem, we advise giving it a try. It considerably simplifies the workflow with multiple libraries shared between various executables.
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.
