[support]

Hi,

It looks like you are using an old VisualGDB version that is not compatible with the latest OpenOCD package.

You can use the regular Tools->VisualGDB->Manage VisualGDB Packages to download the latest version compatible with your VisualGDB, however it will be fairly old as well.

If you would like to use the latest versions of OpenOCD and other tools, please consider renewing your license and updating to the latest VisualGDB.

[support]

Hi,

We would advise using SSH Host Aliases. You can find a detailed tutorial here: https://visualgdb.com/tutorials/linux/aliases/

[support]

Hi,

Thanks, we have managed to reproduce it. Indeed, looks like changing the device profile to sRGB breaks something in the part of the WPF renderer used by VisualGDB.

We will check it again in about a month after Microsoft releases another batch of updates, and if the problem is not fixed on their end, will check if we can add a workaround on our side.

If anyone else runs into this and the workaround doesn’t work, please let us know and we will raise the priority for this.

Edit: we have investigated this further and found the root cause. VisualGDB uses many icons from the Visual Studio Image Library, and apparently, many of them contain embedded color correction profiles that trigger this exception under some configurations (we reproduced it on Win10 but not on Win11). Either way, we have updated our build system to remove the ICC profiles from all icons, so VisualGDB will now work correctly even with the color correction enabled. If anyone else runs into this, feel free to try this build: VisualGDB-6.0.2.4903.msi. The fix will also be included in all VisualGDB versions after 6.0 Beta 2.

• This reply was modified 1 year, 4 months ago by support. Reason: posted a link to the hotfix

[support]

Hi,

Thanks. We actually replied to the email 2 days ago. Please double-check your spam folder for emails from ticket@sysprogs.com.

If you still cannot find it, please let us know and we will resend it.

[support]

Hi,

Our STM32MP1 support is based on the STM32CubeMX examples from ST, and they indeed involve running the ST’s Linux distro on the A7 core, and the barebone code on the M4 core.

There is a 3rd-party set of examples for the STM32MP1 A7 core without Linux. We have briefly rechecked them and they appear to be working, although getting the build to work required some adjustment.

If you would like to get it working with VisualGDB, we would advise the steps below:

1. Build the 3rd-party examples manually and ensure they work. If you get the “failed to merge target-specific data” error while using the regular ARM toolchain, you can work around it by changing the target-specific passed to the linker from -mcpu=cortex-a7 -march=armv7ve -mfpu=neon-vfpv4 -mlittle-endian -mfloat-abi=hard to -mcpu=cortex-a7 -march=armv5te -mfpu=vfpv2 -mfloat-abi=hard (you still need the original files for building the C/C++/assembly files).
2. Try Embedded Quick Debug to debug the built application with the STM32MP1 OpenOCD.  Note that the stm32mp1x.cfg file in the OpenOCD directory opens 3 GDB ports for the M4, and the two A7 cores respectively. VisualGDB connects to the first one, allowing to debug the M4 core. If you would like to debug the first A7 core, you would need to change the GDB port numbers in the file (search for -gdb-port). You can also change it to debug both A7 cores within 1 gdb session by specifying the hwthread RTOS and enabling the smp mode (see the raspberrypi4.cfg file in our regular OpenOCD package).
3. Once you can confirm manual building and debugging, you can easily create a VisualGDB-managed project as shown in this tutorial. You would need to manually specify flags like -mcpu=cortex-a7 -march=armv7ve -mfpu=neon-vfpv4 -mlittle-endian -mfloat-abi=hard, and point VisualGDB to the relevant headers, linker scripts and startup files, but once you do it, the result will be similar to using the Makefiles from the examples repository.

If you wish, we can retest everything on our side and deliver a ready-to-use BSP based on the examples repository. We won’t guarantee that all the examples will work perfectly, but will test the common scenarios like generating UART output, or making sure that both cores run and can be debugged. We will send you a separate email with the quote and the timeframe.

[support]

Hi,

Please make sure you can build and debug the same project for the same device on the same development computer outside VisualGDB (e.g. by building it via command line and running OpenOCD manually). If it doesn’t work, importing it into VisualGDB will not fix it either.

If it does work outside VisualGDB, please let us know and we will help you configure VisualGDB to replicate the manual build results.

[support]

You can try posting the full log from the error message (most of it didn’t fit in the screenshot) and experimenting around to find more context:

• Does it always happens with a specific project/project type or always?
• Is there a specific action that triggers it?
• Does some other functionality (e.g. Quick Debug or editing remote hosts) work?
• Does it work differently with older VisualGDB versions?

But based on the error message, there’s a high chance the root cause is outside VisualGDB with no clear path around it.

[support]

From what we can see, either the icon resources inside VisualGDB (or some system themes) got damaged, or the logic in the .Net framework responsible for decoding them is broken. You can try checking your colleagues’ computers – if anyone else encountered the same issue after a recent update, it can be indeed some strange compatibility between image formats and some Windows update that we could fix. But if only happens on 1 computer, it is unlikely a case of one specific system DLL or setting getting broken.

[support]

Hi,

You can export the build commands used by VisualGDB via the “Dump command line to batch file” command as shown on this page. This should allow you to reproduce the build problem outside VisualGDB and compare the command lines between the working and non-working build.

Our best guess is that some environment variables or other minor parameters are slightly different between the 2 builds.

[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.

[Author]

Posts