[support]

Hi,

This error means that the .Net framework fails to load one of the icons embedded into the VisualGDB resources. Such things are handled automatically by the .Net framework and should not work differently on different computers unless the system is seriously broken.

We have not encountered it before, but the most likely explanation is that some system DLLs responsible for resource loading, or the VisualGDB DLLs got corrupt. You can try reinstalling VisualGDB or using the latest build from the development branch (VisualGDB-5.6.109.4871.msi), but if it doesn’t work, you may need to do a System Restore, or a clean OS reinstall.

[support]

Hi,

You can try copying it like this:

1. Use the OpenOCD (ST Fork) in VisualGDB. DO NOT use the regular OpenOCD.
2. Rename the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.st\share\openocd\scripts directory to scripts.old and re-create it.
3. Copy the contents of the script directories mentioned in the ST command line to the new scripts directory:
   1. C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.0.600.202303311036/resources/openocd/st_scripts
   2. C:/Users/xxxxx/STM32CubeIDE/workspace_1.12.1/TestIDE
   3. C:/ST/STM32CubeIDE_1.12.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mpu.debug.openocd_2.0.500.202301161420/resources/openocd/st_scripts
   4. The share\openocd\scripts from the OpenOCD installation used by STM32CubeIDE (you can search for memory.tcl around STM32CubeIDE to find it)
4. This will re-create the directory structure VisualGDB expects, but will use the scripts from ST. So you can now try running the simplified version of the ST command line (as long as you copied the scripts and are using the VisualGDB’s OpenOCD.exe, you don’t need the ‘-s’ parts):

   openocd.exe -f <full path to TestIDE.cfg>

5. If this doesn’t work, try replacing the VisualGDB’s OpenOCD.exe with the one from STM32CubeIDE. You may need to add the “-s <scripts directory you re-created>” to the command line if it refuses to find the scripts automatically.

[support]

Hi,

The STM32CubeMX project wizard uses a different workflow compared to the regular Embedded project wizard and can only use CMake. If you would like to use MSBuild, please consider generating an STM32CubeIDE project with STM32CubeMX and then importing it into VisualGDB using the regular Embedded project wizard.

The second error looks like you have ended up with an invalid combination of settings. VisualGDB’s automated header discovery feature is designed to automatically search most likely locations for the missing headers, but it’s still up to the user to review the suggestions and double-check that they make sense. If using it ends up breaking the project, please try resolving the build issues manually without using this feature.

[support]

Hi,

No problem. Please try manually running the OpenOCD executable used by VisualGDB with the TestIDE.cfg file from STM32CubeIDE. If it works, you can edit the OpenOCD command line in VisualGDB Project Properties to use the same file.

If not, does it work the other way (OpenOCD executable from STM32CubeIDE copied in place of the one supplied by VisualGDB)?

[support]

Thanks, we have reproduced the problem and it appears to be a bug in the latest Visual Studio. We have submitted a bug report to Microsoft. Feel free to leave a comment there that the problem affects you as well.

[support]

Hi,

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch. See this page for more information and detailed examples.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines.

[support]

Hi,

Updating VisualGDB version should not affect this because the low-level ST-Link interaction is handled directly by OpenOCD (open-source tool with ST-Link support contributed by ST). If your ST-Link revision is new, it may not be supported by mainline OpenOCD yet.

You can troubleshoot it as shown below:

1. Make sure this ST-Link works with STM32CubeIDE (Eclipse-based IDE from Eclipse that also uses OpenOCD).
2. In VisualGDB Project Properties -> Debug Settings select “OpenOCD (ST Fork)”. This will use a version of OpenOCD equivalent to the one in STM32CubeIDE.

If the ST fork still doesn’t work with VisualGDB, the STM32CubeMX might be passing different arguments to OpenOCD in this case. Please feel free to share the OpenOCD command lines by STM32CubeIDE and VisualGDB, and we will help you understand/mitigate the differences.

 

[support]

Hi,

The GNU linker indeed has a few quirks that could be somewhat confusing. A good starting point would be this page that explains the differences between different input types, and also suggests how to obtain extra diagnostic output.

[support]

Hi,

No worries, the files are very intuitive and straight-forward. You can create new files or reference existing files via the action list editors, and then drag-and-drop actions between the regular lists and the shared files. Any settings file (with any combination of action lists) can reference an arbitrary amount of shared lists with optional conditions.

If you encounter any issues, feel free to get back to us and we will help.

[support]

Hi,

No problem, please see this thread for a detailed explanation and a few workarounds.

[support]

Hi,

Good to know it works.

We haven’t specifically tested VisualGDB with FuSa components, however based on the first impression, they look like certified versions of the usual Keil components, so VisualGDB should work with them just fine.

If you encounter any issues, feel free to post the details, and we will do our best to help you.

If you wish, we can also test everything on our side and deliver a ready-to-use development environment with tutorials covering the topics of your interest as a part of our customization services.

 

[support]

Hi,

Does the build produce a lot of output, particularly very long lines? If yes, could you please attach the raw output (from running the .bat file with output redirection)?

Also, could you double-check that Visual Studio doesn’t show any errors about the VisualGDBNative module when you open the project for the first time? It implements a few optimizations, namely a fast regex parser used for build message translation.

[support]

Hi,

We are aware that the STM32CubeMX generates the assembly files with the lowercase extension, but so far, the examples we’ve seen did not depend on the preprocessor. It makes sense that AzureRTOS would handle it differently.

We have updated VisualGDB to automatically rename the files on importing. Please try this build: VisualGDB-5.6.109.4864.msi

[support]

Hi,

This looks like the new kernel has a slightly different configuration (has function tracing API enabled), but is using the older API. Either way, we have updated VisualKernel to handle it correctly: VisualKernel-4.0.101.2374.msi

The new build also fixes the 3-machine issues you described earlier, and improves tracing of inline functions.

[support]

Hi,

Oops, sorry about the trace data window glitch. It was a side effect of another last-minute fix. Please try this build: VisualKernel-4.0.101.2372.msi

It also fixes the in-code tracepoint links for inline functions and functions with discontiguous ranges (they were previously traceable via the New Tracpoint button, but not via code).

[Author]

Posts