[support]

No problem, we have rechecked both remaining issues. The logic for moving the solution file was indeed not used when importing CMake projects, and the logic handling rebuilds contained a glitch that didn’t work with some combinations of settings. We have fixed it in this build: VisualGDB-6.0.107.5300.msi

[support]

Sorry, we don’t have any further advice beyond what we already mentioned.

[support]

Hi,

No problem, this is indeed a separate issue. That said, it shouldn’t be VisualGDB-specific. VisualGDB uses the same low-level debugging tool as the STM32CubeIDE, and both ultimately show the values they receive from the chip via the debug interface. There might be some device register or OpenOCD command overriding this behavior, and turning it on will fix the problem regardless of the IDE you are using, but VisualGDB cannot do it automatically.

[support]

Sorry, this doesn’t look like any known issue. Please try following the tutorials from scratch, make sure it works there, and then try comparing the broken project against the working one. If you can point out a specific setting that consistently triggers the problem, we might be able to suggest a workaround.

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

Looks like something is broken with the symbols. Please make sure you understand which symbols are loaded, which paths are referenced by them, and what paths are expected by gdb.

[support]

Hi,

Due to historical reasons, the maximum memory size shown in the build output and in the Memory Explorer is fixed for each device type. It doesn’t affect anything other than the displayed utilization, so for the devices with variable size we usually just take the default value from the default vendor-supplied linker script.

You can always patch it on your side by editing the MemoryMap tag in BSP.XML under %LOCALAPPDATA%\VisualGDB.

Another option would be to configure VisualGDB to infer the memory map from the linker script (requires Custom edition) via VisualGDB Project Properties -> Memories.

[support]

Hi,

Please refer to the following thread: https://sysprogs.com/w/forums/topic/debugger-setup-for-black-magic-probe/

[support]

Hi,

Sure, this is already supported. You can use the Debug->Windows->Hardware Registers window, locate the appropriate pin status register (see the device datasheet for the exact name) and turn on the live mode for it (lightning bolt icon). You can also flag several similar registers as favorite, so you can quickly view their realtime values without having to locate each one individually.

[support]

Hi,

Looks like VisualGDB fails to generate BSP.cmake due to some error with the gpdsc file:

VisualGDB found an error: Файл ‘C:\Users\user\mySpace\workspace\_superior\stm32Project\firmware\TestFirmware\TestFirmware.gpdsc’ РЅРµ найден.

Please double-check the error message on your computer. If it’s still unreadable, please consider changing the message language to English via environment.

[support]

Hi,

The regular C++ cast expressions should work just fine. Either way, VisualGDB passes the watch expressions directly to GDB (you can achieve the same result by running “print <expression>” in the GDB Session window and check the GDB documentation for the supported syntax.

[support]

Hi,

VisualGDB passes the file name and arguments directly to ProcessStartInfo, so the behavior regarding path, etc is defined by it. You can try calling this function directly with different combinations of parameters to see what works the best.

[support]

Hi,

You can try building it with Arduino IDE. If the build time is the same on the same machine for the same project, it is not something VisualGDB can fix. If the build time is considerably different, we can help you track it down.

[support]

Hi,

Thanks for the detailed feedback. We have addressed most of the issues in this build: VisualGDB-6.0.107.5295.msi. Specifically:

1. We have added a checkbox for relocating the project file to the imported project’s directory, similar to imported STM32Cube/IAR/Keil projects. It is located under the import mode selection switches.
2. The device selection tab is needed because many parts of VisualGDB (debug engine, tracing engine, live memory engine, etc) can enable various optimizations if the device type is known. You don’t strictly need to set it and can proceed with the empty “manual” mode or pick any similar device, but you may end up needing to manually fine-tune debugging or configure other parts of VisualGDB.
3. The CMake binary is pre-loaded based on other settings from the previous page (e.g. whether you are building it remotely). We could theoretically add logic for checking whether these settings got changed after changing the CMake path, but given that the non-default paths are used rarely, going back and forth through the pages is also not very common, and the workaround is trivial, we would rather not add any additional complexity to that part.
4. There was indeed a bug with the CMake presets. Importing a preset without a build directory would show a rather generic error message, and if you configured the directory manually, it would not be applied until you reopen the project. We have fixed both issues: instead of the generic message, VisualGDB now clearly asks if you want to review/adjust the presets (where the missing value is immediately highlighted), and the changes are properly applied without having to reopen the project.

[support]

Hi,

Thanks for the screenshots. With the variable values it looks like conflict between the bootloader symbols and application symbols (both have the same variable defined at different places). We have added another step to the application tutorial showing how to avoid it by disabling bootloader symbols and debugging only the application.

The second error is caused by a workaround that is no longer required with the latest GCC. We have fixed it in our development branch, and you can apply it on your side by removing these lines from %VISUALGDB_DIR%\gcc_compat.h:

#ifdef __ARM_EABI__
#define __LDREXW(expr) *(expr)
#define __STREXW(expr, val) expr
#endif

[Author]

Posts