[support]

Hi,

Strange. Could you please attach a screenshot of your Help->About VisualGDB window so that we could see what is going on?

[support]

Hi,

Both hex and bin files are generated from the ELF file using the arm-none-objcopy.exe tool. The .bin file will fill the empty areas with 00’s, while the hex file will actually skip them (that translates of 0xFFs when erasing and programming FLASH). If you are using MSBuild, you can configure VisualGDB to fill the .bin files with 0xFF’s via MSBuild Project Properties -> Embedded Project -> Fill gaps in .bin file with.

For other project types (e.g. CMake) there is no easy setting to do that, but you can still run arm-none-objcopy.exe manually as a post-build step, passing it the –gap-fill argument with the desired value. You can find more information in the documentation for the objcopy tool.

[support]

Hi,

The GPDSC support in STM32CubeMX has been discontinued for a while, so the latest VisualGDB 5.6 already uses the STM32CubeIDE project generator in STM32CubeMX instead of the GPDSC generator. That said, it only affects the new projects. If you have an existing project, you can try updating it as shown below:

1. Open the .ioc file in STM32CubeMX.
2. Manually switch the toolchain to STM32CubeIDE.
3. Manually generate the code and save the STM32CubeMX project.
4. Delete the .gpdsc file generated before the switch.

Next time you open the project in VisualGDB, it will continue using the STM32CubeIDE generator instead of the GPDSC generator.

That said, switching an existing project to a new generator may trigger bugs in STM32CubeMX that might require some manual fixes. If the project doesn’t build, please consider creating another one from scratch and comparing the generated files side-by-side.

[support]

Hi,

This looks like your firewall/proxy server is preventing VisualGDB from downloading the toolchain installer. Please consider adding VisualGDB to exception list, or simply downloading it manually here.

[support]

Hi,

You can use the $(TargetPath) expression to reference the built file path. Ultimately, the custom build steps are simply instructions to run custom command-line applications or scripts. The actual logic for editing the files would need to be done by the actual script.

[support]

Sorry for the late reply. We have discovered a breaking change in ESP-IDF 4.4 that affected unit tests, and had to resolve it. We have updated VisualGDB to support running ESP-IDF unit tests automatically. You can now use the following command line to do so:

VisualGDB.exe /runtests <file.vgdbproj> /targetpath:<full path to the .elf file> /output:<XML file with results>

It should work for all submodules/components that get linked into the same ELF file. You would need to use the following build: VisualGDB-5.6.104.4547.msi

That said, your support period had recently expired. Although this build will work with your key, we advise renewing your key here to get access to further VisualGDB updates and technical support.

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[support]

Thanks for clarifying it. If the solution contains multiple projects, switching it to CMake could have the benefit of separating orthogonal settings:

• Platform-specific settings (e.g. which compiler to use, global optimization flags, etc.) could be stored in a VisualGDB CMake project file
• Target-specific settings (which executables/libraries to build, how do they depend on each other, etc) could be stored in CMakeLists.txt files

You can read more about it here: https://visualgdb.com/tutorials/cmake/multiplatform/

But, if you already have a complex system of MSBuild projects and do not want to change it, using a simple script to convert the settings should be the best approach. You can read more about manually adding VisualGDB platforms in this tutorial. Also, if you need help understanding specific settings, feel free to let us know.

[support]

Hi,

The logic for adding configurations is indeed intended for the regular Win32 projects, so that you could have Win32 configurations in parallel with VisualGDB configurations. The regular VS Linux projects use a different layout and the configuration adding logic won’t work for them.

The easiest way to import an existing project into VisualGDB would be to use the import mode of the wizard. It will automatically add all sources and headers from the specified directory to the new project, although you would need to specify other settings (e.g. preprocessor macros) manually.

You can also try using CMake to build your project. VisualGDB integration with CMake is far more advanced compared to the regular VS one (e.g. see our CMake script debugger) and at the same time will give you an easy option to build the project outside VisualGDB if you ever need to do so.

[support]

Hi,

This is correct. Qt-specific items can be added via the “Add Existing Item” command, or by editing CMakeLists.txt file manually.

[support]

Hi,

The mechanism for retesting the toolchain with every setting change is only used in the legacy GNU Make-based project type. Newer MSBuild-based and CMake-based projects do not need it and should generally work better (also building the project after changing settings will be faster). If this is not an option and you need to use GNU Make, you can simply ignore the “toolchain testing failed” error.

[support]

Hi,

The standard C library provides a few functions faster than printf(). They all work via the same backend provided by the fast semihosting. You can get a good overview by setting a breakpoint at WriteToFastSemihostingChannel(), calling printf(), checking the call stack involved in the call, and manually calling some of the lower-level functions shown in that call stack. Using puts() could be another option.

Regarding STM32CubeMX, its output usually varies a lot between different versions (and is often buggy), so we try to steer clear of adjusting anything automatically to avoid breaking it even further. Patching it manually could be a reasonable workaround (just make sure you check in the generated files into source control). Another option would be to use the “Exclude from build” command in Solution Explorer to ignore the entire file.

[support]

Hi,

The SRAM option works the same for all devices – places all code and data into SRAM. This allows testing out the code without programming the FLASH memory, that could be faster in some times.

If you wish to copy the code from FLASH to RAM, you would need to handle it manually. VisualGDB does not have any special GUI setting for it. If you need a quick example or an explanation how to do it, feel free to reach out to our sales email for a quote.

The OpenOCD support for new devices is usually introduced a few months after a device has been released. ST shares it with the OpenOCD developers, they push it into the master branch, and our build system picks it up. Until then, there are a few options to use the device:

• Select “do not program FLASH” in VisualGDB Debug Settings and use the STM32CubeProgrammer as a custom pre-debug step
• Use Segger J-Link that usually supports new devices earlier
• Try selecting the ST fork of OpenOCD in the VisualGDB Debug Settings
• If the patches for the new device are in review, you can manually apply them to OpenOCD and rebuild it

[support]

No problem. If you ever get more weird behavior with ITM, feel free to try the live watch with counter test – it should reveal memory reading problems fairly fast.

Also, feel free to check out the Test Resource Manager. It may prove useful for complex setups (e.g. you can write multiple binary log files and analyze them programmatically later).

[support]

Hi,

It looks like your VisualGDB installation is corrupt (missing MSBuild platform), or you have edited the project in a way that breaks MSBuild integration. In order to resolve it, please try:

1. Uninstalling VisualGDB completely and deleting its directory
2. Installing it again
3. Following the tutorial to the letter to create a new project from scratch.

If it still doesn’t work, 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.
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, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[Author]

Posts