[support]

Hi,

Looks like the video is private and won’t download without a login (that won’t work on our isolated repro VMs). Please consider sharing it publicly as described here or use a different service that does not require logging in.

If you do not wish to share the steps publicly, please consider placing the video into an encrypted archive, and sending the password via our support form.

[support]

Thanks, we will look into it and release a repackaged toolchain within the next 2-3 weeks.

[support]

Hi,

Thanks for the suggestion. COM port aliases look interesting, although, based on a very brief research, it doesn’t look like a very frequently used feature.

Hence, we would like to hear more feedback from other users first. If anyone is using COM port aliases and would benefit from VisualGDB displaying them (as opposed to entering the COM port manually), please feel free to comment in this thread.

[support]

Hi,

Based on what we see, it looks like you have several files with very similar paths, and some mapping rules that look almost correct, but are off in some very subtle way.

In order to fix it, you would need to double-check all the paths and mappings.

First of all, please remove all secondary projects from Solution Explorer, so you only have 1 project )it will only affect the .sln file). This will ensure you are changing the settings for the same project that is generating the error messages (otherwise the settings will not change anything). Then, please share the screenshots of the following:

• The exact error message shown when you try to open the file.
• The exact message in the build log (VisualGDB Output -> Build -> Log, not the error list).
• The Project Settings, Synchronized Directories and Path Mappings pages of VisualGDB Project Properties.
• Solution Explorer showing only one project in the solution.

Once you get it working with just one project, you can try restoring the .sln file from the backup, or re-adding the projects manually. If the problem starts happening after adding a specific project, please let us know and we will advise you on the troubleshooting steps.

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

[Author]

Posts