[support]

Sorry for the delay. We have finally managed to reproduce the issue and it turns out it was caused by a race condition in the hardware register window initialization logic.

We have fixed it in the following build: VisualGDB-5.6.104.4554.msi

[support]

Hi,

No problem, we can gladly build a toolchain for you. Feel free to contact our sales with the details about your target and we will give you a quote.

[support]

Hi,

This looks like an issue between the module and the Espressif’s port of OpenOCD, and hence is not directly controlled by VisualGDB. Please consider contacting Espressif for further help with this issue.

You can also try reproducing it by manually running the OpenOCD build from the Espressif github repository. It it works better, we can help you configure VisualGDB to replicate the correct behavior.

Update: we got another report of a similar issue in this thread, and the workaround suggested on the Espressif forums is to pass the “esp appimage_offset 0x20000” command to OpenOCD. With VisualGDB, this can be done by adding the following text to the end of OpenOCD command line in VisualGDB Project Properties -> Debug Settings -> Advanced:

-c "esp appimage_offset 0x20000"

• This reply was modified 1 year, 9 months ago by support.

[support]

Hi,

In order to build the Linux applications on Windows, the cross-toolchain needs to be built specifically for that target using precisely the same settings as the original gcc. I.e. it needs to use the same ABI settings, same versions of libraries, same distro-specific gcc patches, and so on. Synchronizing sysroot on a similar toolchain would lead to unpredictable consequences: it might work, or it could trigger strange compile-time or runtime issues. You can read more about it here: https://visualgdb.com/documentation/linux/boards/.

If you are using a custom Linux board, the board vendor might already provide a toolchain, or scripts for building one. We could also build one for you for a small fee. Feel free to reach out to our sales to get a quote.

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

[Author]

Posts