[support]

Hi,

If VisualGDB adds the “-select IP=127.0.0.1:2331” argument, it means that you have changed the connection mode from “USB” to “TCP/IP”, that doesn’t match the screenshot you provided. If you manually change the “-port” argument to 2331, it will not work because JLinkGDBServer will try to use the same port to connect to GDB and J-Link hardware (that should be using USB instead).

Please do not do this. Changing random settings without understanding them, and mixing screenshots and logs from different setups never works and makes it completely impossible to troubleshoot anything.

If you still cannot get it working, please try creating a new project from scratch, selecting J-Link via debug settings and then:

1. Using the “test” button to verify the connection without changing any other settings.
2. Running the exact command line from the “test” window without changing anything else.
3. Running GDB manually, and connecting to the port specified by “-port“.

If it doesn’t work, please attach:

1. The screenshot of the debug settings
2. The entire log (including command line) from the test window
3. The entire output (including command line) when running JLinkGDBServerCL manually
4. The entire output (including command line and all commands) from gdb

If you change anything else, please do explicitly mention it and make sure your screenshots reflect it. Otherwise, it will not work.

[support]

Hi,

There are 2 different ports involved in it. The one passed via -select refers to connecting JLinkGDBServer to J-Link hardware via TCP/IP (as opposed to USB). The one passed via -port refers to the port used by gdb to connect to JLinkGDBServer.

You can try clicking the “test” button on the Debug Settings page of VisualGDB Project Properties. It will launch the J-Link GDB server and will show the used command line. You can then try closing it, running it manually, and then starting GDB (pointing it to the correct ELF file) and running the following commands:

target remote :<GDB port specified via -port>
load
b main
continue

If this works (i.e. breakpoint in main() triggers), but debugging with VisualGDB still doesn’t work, please attach the gdb log from VisualGDB along with the output from running the gdb commands manually, and we will help you find the difference.

 

[support]

Please make sure you can run the J-Link gdb server manually, connect gdb to it and debug the ELF file produced by the Arduino project.

Once this works, feel free to share the details (e.g. exact J-Link gdb server command line that worked), and we can help you configure VisualGDB to replicate that setup.

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

[Author]

Posts