[support]

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]

Hi,

Please refer to your Linux distro documentation for instructions on installing gdbserver and other tools.

[support]

Good to know it works. That said, Visual Studio should normally set the PATH automatically, so the problem could have been solved by simply restarting VS.

[support]

No problem and good to know it works. If you encounter further issues, feel free to create another thread.

[support]

Thanks for the screenshot. This build should work just fine. Please try running the build from command line:

msbuild.exe <.sln file> /p:Platform=VisualGDB /p:Configuration=Debug

If it also hangs, please try obtaining a stack trace of the msbuild.exe process as shown here.

If the manual build works, but the build from VS does not, please try closing ALL VS instances, starting just one, and doing the build again. Once it hangs, please try checking the call stacks of all MSBuild.exe processes (VS would normally launch multiple ones) and searching for the ones having VisualGDB methods on the stack.

[support]

Hi,

In order to select the exact set of tests to run, VisualGDB sets a breakpoint in the SysprogsTestHook_SelectTests() function and reads/writes the variables pointing to the test that are about to run. Most likely, the optimizer is somehow interfering with this variable in your case.

We would advise enabling the GDB logging via VisualGDB Project Properties, checking the exact gdb commands sent by VisualGDB when the breakpoint in SysprogsTestHook_SelectTests() triggers and double-checking that they succeed (i.e. the actual memory gets modified). If not, you may need to disable optimization for the corresponding source file, or reorganize the code (e.g. promote some local variables to global ones to prevent the optimizer from removing them).

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

[Author]

Posts