[support]

Hi,

Sorry, we haven’t specifically tested VisualGDB with gRPC and do not have any instructions for it. Our best advice would be to first get it working outside VisualGDB using the same target/toolchain, and then modify your VisualGDB project accordingly.

[support]

Hi,

The “must specify support pico_cyw43_arch architecture” error could be triggered when trying to build Pico W samples for the regular Pico board or vice versa. Please make sure you select the PICO_W target in the wizard if you are using Pico W samples.

The other message looks like something in the SDK is broken. You can try resetting the SDK installation as follows:

1. Completely delete the toolchain directory.
2. Completely delete all PicoSDK checkouts from %LOCALAPPDATA%\VisualGDB\PicoSDK.
3. Completely delete CMake from %LOCALAPPDATA%\VisualGDB\CMake
4. Restart Visual Studio.
5. Create a new Pico SDK project completely from scratch, letting VisualGDB download all necessary tools.

 

[support]

Hi,

The “Easy GUI for managing additional memories” in the Custom edition refers to this feature. It provides a GUI for adding memories and associated sections to linker scripts instead of editing them manually. It only works for classic embedded projects (not Arduino/Mbed/ESP-IDF). If you do not need this feature, or any other Custom/Ultimate features, you can contact our support, and we will revert the upgrade.

If you would like to get debugging working on WLR089, please make sure Segger J-Link actually supports it and can work with it via command line (by launching their gdbserver manually). If J-Link cannot communicate to the chip, using VisualGDB on top of it won’t automatically fix it.

[support]

Hi,

This is by design. You can try using the “Run All Tests” or “Run Selected Tests” commands to run multiple tests. VisualGDB will record the call stacks for the failing ones, and automatically continue running the remaining tests. Then, once you narrowed down a specific failing test, you can run just that test in debugger, and VisualGDB will automatically stop the debug session when the test failure occurs. You can still press F5 to continue to the next test though.

If this doesn’t work, feel free to describe what you are trying to achieve, and we will try to suggest a better way to do it.

[support]

Hi,

Thanks for sharing this. Normally, the main difference between the “target extended-remote” and “target remote” is about being able to restart the debugged program without restarting the debug session. It makes sense for debugging Linux programs (being able to start the program again without manually restarting gdbserver), but doesn’t change much for the embedded workflow where the target program never truly “exits”, hence we never changed the default command used by VisualGDB.

Either way, it using target extended-remote works around the programming bug, you can use it instead of target remote. The rest of the functionality should work the same.

We have also released an updated OpenOCD package (20240820-0.12.0) that uses target extended-remote by default.

[support]

Hi,

We have just rechecked it with a basic STM32F746NG project using the latest toolchain, latest GDB and the latest OpenOCD, and it worked just fine.

Most likely, something about your project is triggering a bug in some of the tools. Please try narrowing it down as follows:

1. Double-check that switching to the old toolchain, but keeping the latest OpenOCD fixes the problem. You can also check if using the previous OpenOCD with the new toolchain works (normally, the toolchain should not affect the FLASH programming at all). Make sure you fully rebuild the project after switching the toolchain.
2. If the problem is specific to the toolchain and is not affected by OpenOCD, try copying the old gdb executable into the new toolchain. Does the problem still trigger?
3. If the problem happens with the new toolchain and old GDB, it can be triggered by some optimization done by GCC. You can try comparing the 2 builds of the project with Embedded Memory Explorer. Is there something particular about the broken version (e.g. some section alignment is off, or some new sections have appeared)?

[support]

Hi,

The screenshot shows the include directories provided by the toolchain. The number there refers to the GCC version and not the language standard. If you need a newer gcc, you would need to check if your platform vendor provides one.

The language standard version (e.g. C++11 or C++23) can be configured via VS project settings (not VisualGDB Project Properties) -> C/C++-> Advanced -> Language Standard.

[support]

Hi,

The easiest way would be to manually patch the .vcxproj file, conditionally adding/Zc:__cplusplus when the DesignTimeBuild variable is set. This should affect IntelliSense, but not the actual build.

Another option would be to checking the _MSC_VER macro in some common header file, and redefining __cplusplus if it is set.

[support]

Hi,

Sorry, this is the side effect of how per-target building is handled. VisualGDB shows relevant CMake targets in Solution Explorer and allows building them via context menu. Generation of binary/hex files is done via separate CMake targets, so when you request CMake to build the actual executable target, it won’t build those.

If you have a complex scenario where another target requires these files, you can add an explicit dependency from that target to the binary file-building targets, so CMake will build them whenever it builds the target using them.

[support]

Hi,

No problem, we can try to help you. Please let us know the email address associated with your license, so that we could link it to your support profile.

[support]

Hi,

The VisualGDB setting for removing the debug info would be Linker->Advanced->Strip Debug Information. It enables the “-Wl,–strip-debug” option mentioned by @bflannery.

But you can also add a post-build step for stripping it, moving it to a separate symbol file as shown here.

[support]

Hi,

Our BSPs are directly derived from the device SDKs provided by the device vendors (ST in this case). You can find out the exact SDK versions used to build each BSP in the SDKVersions.xml file (STM32 only) and then check the SDK changelog on the ST website.

[support]

Hi,

We have just rechecked the rename command using Clang IntelliSense and it worked just fine; hence, the issue is likely used by something else.

In order to narrow it down, please try creating a new project from scratch, right-clicking in the middle of the “main” word of the main() function and selecting “Rename”. Does it work? If yes, please try checking:

1. Does the key combination work for the newly created project?
2. If yes, does it work for other symbols in the main project?
3. If yes, is there something particular about the symbols that cannot be renamed (e.g. defined in .h files, but not .c files)?

[support]

Hi,

No worries, we have released an updated toolchain package. You can now install it via VisualGDB Package Manager, or get it directly from here: https://gnutoolchains.com/esp32/

[support]

Hi,

VisualGDB Properties are merely a GUI for editing various ESP-IDF statements. Please refer to the ESP-IDF documentation to see if there is a statement that would cover your use case.

If you can point out a specific statement (i.e. would know how exactly to edit the CMake files to get the desired result), we can advise you on the GUI setting that would do it for you.

[Author]

Posts