[support]

Hi,

This looks like an issue between a particular ST-Link and the target. It could be caused by wiring, broken target, or something else. You can try getting it working with STM32CubeIDE first. If it works there and doesn’t work with VisualGDB, we can help you compare the OpenOCD command lines and get it working as well.

[support]

Hi,

It is fully supported starting from the 6.0.4 builds (e.g. VisualGDB-6.0.4.5075.msi). We have tested it on the latest Apple M3 Max and it works just fine (that said, getting drivers for some JTAG programmers to work could be tricky).

[support]

Hi,

Sure, feel free to reach out to our sales, and we will give you a quote.

[support]

You can try contacting the device vendor, or your supplier. Maybe, they could have some suggestions.

As far as VisualGDB is concerned, it runs OpenOCD in order to handle the low-level debug functionality. The STM32 support in OpenOCD is developed by ST and generally works very well with genuine ST devices. If it’s not working with a particular device, the issue is somewhere between OpenOCD and that specific device. If you can get OpenOCD working via command line, we can help you configure VisualGDB to use that command line when you start a debug session. If not, it won’t work with VisualGDB either.

[support]

Hi,

The ST-Link devices are specifically designed to work with ST microcontrollers only, so it makes sense that they wouldn’t work with APM32. You can try contacting the device vendor- maybe they supply their own version of ST-Link or OpenOCD.

[support]

Hi,

No problem, please try this build: VisualGDB-6.0.4.5073.msi

We have added a context menu command for saving the selected register values (including all subregisters):

The CSV file created with this commands contains 3 columns: the register name, raw hex value (regardless of the actual register size) and the formatted value according to the current settings.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

That’s because the tutorial is for STM32L0 and you are using STM32H7. These are different devices with different OpenOCD scripts that work slightly differently.

If you are not sure which line to edit, you can try asking on the STM32 forums or OpenOCD mailing lists, but VisualGDB cannot figure out the necessary edits automatically.

[support]

Hi,

The only change in the settings since the tutorial is that instead of selecting the “manual mode” and editing each script manually, you can now open the “advanced” view and edit the OpenOCD command line directly. The rest of the tutorial should still apply.

[support]

Hi,

This looks like your firewall is interfering with the network connection in some way. You can try downloading the toolchains/BSPs manually or adding VisualGDB to the exception list.

If you are normally using a proxy, you can configure it via Tools->Options->VisualGDB->General->Other->Proxy Server.

[support]

Hi,

Generally, it should work. However, for large projects, the profiler can sometimes have unintended side effects (e.g. causing stack to overflow due to requiring some extra stack space).

You can troubleshoot it as follows:

1. Try to instrument as little functions as possible. If it stops the problem from happening, some of the profiled functions might me manipulating the stack directly, or otherwise interfering with the profiler. You can narrow it down by instrumenting half of the functions at a time and seeing which half breaks.
2. Try checking the functions shown in the profiler window, or the variable values inside the profiler framework. Sometimes, it points to an obvious location that causes the problem (typically, a function manipulating the stack).

You can also try using the new Software Tracing introduced in VisualGDB 6.0. It is much less intrusive, can record the ARM cycle count each time the given line (or function) gets executed, so you can get precise timing on the function or even line level, and export it to Excel for a detailed analysis.

[support]

Hi,

VisualGDB uses the GNU Linker to link the built executables. You can pass additional flags to the linker via project properties (exact location depends on the project type). That said, we are not aware of any linker setting that would pad the ELF file up to the size of the MCU FLASH. You might be able to get it working with some tweaks to the linker script, but it’s not something that VisualGDB can do out-of-the-box.

[support]

For ESP-IDF and other CMake-based projects, the platforms/configurations are just a way to quickly pass different parameters to CMake. Normally, the configuration translates to the CMAKE_BUILD_TYPE value, and the platforms can be defined arbitrarily, with each platform having its own CMake flags.

This mechanism is completely separate from the regular MSBuild-based platforms and configurations. It is not designed for building ESP-IDF code for x86 and will not work even if you manage to somehow hardcode the x86 platform.

[support]

Hi,

The ESP32 projects work on top of the ESP-IDF build scripts. VisualGDB does not directly manage the build process for them, there are no MSBuild-style platforms and configurations (even file lists and settings are stored on ESP-IDF level), hence just adding an x86 platform it it won’t work.

Unless you are willing to port the ESP-IDF build scripts to support x86 builds, it would be way easier to create a separate project.

[support]

Hi,

Sorry about that, it’s actually a VisualGDB bug. It was handling the source, rsource and osource directives, but not orsource. We have fixed it in the following build: VisualGDB-6.0.4.5058.msi

[support]

Hi,

No problem, we will try to help.

VisualGDB used to follow this layout (stored relative paths for toolchains inside the project files), however most users would not want to check in the toolchains, and would instead have them installed manually, often in different paths.

So, we moved the logic for ensuring toolchain consistency to VisualGDB:

1. Each toolchain always has a unique ID/version combination (see toolchain.xml).
2. Each project always references a specific ID and version.
3. When you open a project, VisualGDB checks if the exact toolchain it references is installed, and uses the location when running all the tools without hardcoding it in the project file.
4. If the toolchain is not installed, but comes from us, VisualGDB suggests automatically installing it.

So, you have all the advantages of a checked in toolchain (solid versioning, each project referencing a specific version, having multiple versions installed at once) without having to overload the Git repository with rather bulky toolchains (yes, it could be a submodule).

So, to the points you mentioned:

1. You don’t actually need to coordinate toolchain updates. Assume, you wanted to switch the project from gcc 10 to gcc 12:
   1. You change the toolchain via VisualGDB GUI project files and check in the project files.
   2. Users who check out the new project version will get a prompt asking them to download the new toolchain. They could install it side-by-side with the old one (to a different directory).
   3. When they open the older version of the project, VisualGDB will automatically use the old toolchain. If they open the newer version again, VisualGDB will use the new one.
2. The toolchain version is transparently stored inside the project files. The only issue is that if you have multiple projects in the same repository, switching the toolchain would require updating all relevant project files, as opposed to just 1 git submodule reference.
3. Reviving old projects should be fine, as long as you keep the toolchain installers. If you are using our toolchains, you can download them from https://gnutoolchains.com/ and install them manually later.

So, in essence, it already works very similar to a git submodule managed by VisualGDB on a per-project basis.

We could try adding some sort of workaround for relative references, but it won’t work with the regular GUI and may cause conflicts between toolchains referenced by version and toolchains referenced by relative path. On the other hand, we could update the current toolchain system to address some of the issues you mentioned:

• We could allow adding custom toolchain repositories (e.g. SMB shares with toolchain installers), so you could backup the installers, point VisualGDB to the repository and have it install the necessary toolchains on-demand without depending on our servers.
• We could add indirect toolchain references. Where each project will reference a “toolchain version file”, that will contain the toolchain ID and version. If you would like to retarget multiple projects to a new toolchain, you would edit that single file (similar to updating a git submodule reference) and VisualGDB will recognize it and use the new toolchain for all projects using that file.

[Author]

Posts