[support]

Hi,

This is something to check on the Raspberry Pi forum. As far as VisualGDB is concerned, if valgrind itself works as expected, VisualGDB will work with it as well.

[support]

Hi,

Thanks, indeed there was a glitch with the Keil components triggered by the 64-bit runtime used by VS2022. We have fixed it in this build: VisualGDB-5.6.102.4516.msi

With the pack versions, indeed VisualGDB only recognizes the latest one. We will look further into it and provide an update here regarding the possible workarounds in the next couple of days.

Update: the multiple pack versions work just fine as long as you select the correct pack version in the device selector (first page of VisualGDB Project Properties). Then, VisualGDB will use the component list from the corresponding version of the pack.

• This reply was modified 3 years, 6 months ago by support. Reason: explained multiple pack versions

[support]

Hi,

It looks like valgrind may not be 100% compatible with your version of Raspberry Pi OS yet. You can try installing an older version of the OS/toolchain thta might work better (see this page) or submitting this issue to valgrid developers, so that they could consider fixing it.

[support]

Thanks for letting us know.  Segger J-Link supports a huge variety of devices very well, and has its own support dedicated to this type of low-level issues. Feel free to check with them whether your specific device is supported, and forward them any J-Link-level messages you get.

If you do not wish to use J-Link, you can try debugging:

1. A “LEDBlink” project for the same chip/board using VisualGDB.
2. A “LEDBlink” project for the same chip/board using STM32CubeIDE.

If the #1 doesn’t work, while #2 works, you should be able to fix VisualGDB-based debugging by copying the additional initialization commands from STM32CubeIDE.

If debugging a “LEDBlink” project works, while debugging your current project doesn’t, it could be an OpenOCD bug triggered by something about the project layout. Comparing the project to the LEDBlink project could help understand it.

You can also try building OpenOCD yourself and stepping through its logic, although it could be a tricky endeavor.

[support]

Hi,

This looks like an issue in OpenOCD, rather than VisualGDB itself. You can resolve it in one of the following ways:

1. Try using Segger J-Link with the J-Link software instead of OpenOCD. The Segger software is generally much more reliable than the open-source tools.
2. Alternatively, please try selecting the ST fork of OpenOCD in VisualGDB Project Properties -> Debug Settings instead of the regular OpenOCD branch. The ST fork uses a slightly different code base, that might work better in some cases.
3. If it still doesn’t work, please try installing the STM32CubeIDE and debugging the device with it. If it works, try comparing the OpenOCD script generated by STM32CubeIDE with the one used by VisualGDB (see VisualGDB Project Properties -> Debug Settings for the exact OpenOCD command line). The ST script might include some additional commands that are not present in the regular scripts used by VisualGDB. Adding them manually to the OpenOCD command line (or creating a copy of the STM32CubeIDE script and pointing VisualGDB to it) should replicate the results from STM32CubeIDE.

[support]

Good to know it works. Indeed, a missing extern “C” is a common cause for hard-to-track errors when using C and C++ code together. In case anyone else runs into similar issues, we have a detailed tutorial explaining it here: https://visualgdb.com/tutorials/tips/externc/

[support]

Thanks for renewing your technical support.

Locally-built MSBuild projects support generating batch files to build the projects outside Visual Studio (see this page for details). A batch file will contain a list of gcc/linker command lines referencing the response files (.rsp) that contain the actual GCC command lines. The response files are used to bypass the Windows command line length limitation.

If you would like to build the same project on Linux, we would advise following the steps below:

1. Enable the generation of batch files and make sure the generated batch file works on the Windows machine.
2. Create a basic tool/script that will parse the batch file and replace Windows-specific paths with their Linux equivalents (don’t forget to convert CRLF line endings to LF and the ‘REM’ comments to ‘#’)
3. Once the substitutions are performed, you can try running the updated script file on Linux. It will invoke gcc/linker with the same arguments that should result in a successful build. Once you confirm that it works manually, running it from the CI system should be straight-forward.

Note that as Linux does not have a command line length limitation, you can expand the references to the .rsp files in-place, e.g.:

gcc @debug/file.rsp

where file.rsp contains

-IC:/dir test.c -o test.o

can be expanded to just:

gcc -I/path/on/Linux/dir test.c -o test.o

 

[support]

Hi,

No problem. You can simply send us your license key (or email address associated with it) and a link to this post via our support form and we will link them together.

[support]

Thanks for letting us know and good to know it works. This makes sense, since VisualGDB relies on TCP/IP to communicate with WSL.

[support]

Hi,

ESP-IDF 5.0 is not a stable release. It might be buggy, incompatible with tools like OpenOCD, or might be missing some functionality. Unless you are fine doing the troubleshooting on your side, please consider using stable releases only (e.g. ESP-IDF v4.3.1).

[support]

Hi,

We do not have a dedicated tutorial for Visual Watch, however it is featured in our STM32 ADC tutorial.

[support]

Hi,

This is generally possible, although might require some adjustments and troubleshooting due to differences between Windows and Linux.

If you could let us know the build system you are using (GNU Make, CMake or MSBuild), we can point you to the right direction.

Please also let us know the email address associated with your license key (or update the forum profile accordingly), so that we could link your support profile to the forum profile.

[support]

Hi,

No problem, please try checking the following:

• Does VisualGDB work with the same WSL distro using the default toolchain (not the Yocto one)?
• Does 172.22.240.1 correspond to the correct WSL network adapter? Is IPv4 enabled for it?
• Are you able to ping 172.22.240.1 (that should correspond to the Windows machine) from WSL and use it to telnet to TCP ports opened on the Windows machine?

[support]

Hi,

This value comes directly from gdb. Please consider checking the gdb documentation for commands controlling it. You can add these commands to VisualGDB Project Properties -> Additional GDB Commands.

[support]

Hi,

Although ESP32-C3 is indeed based on RISC-V, based on our experiments, the ESP32 OpenOCD could not read the target memory without stopping it, hence Live Watch won’t work. We have briefly checked with Espressif and it should be theoretically supported, although might require some patching on the OpenOCD side.

We will look further into it during one of the next OpenOCD updates and will try to get live watch for ESP32-C3 working, although we cannot promise anything at this point.

Edit: we have created a Github issue regarding the broken background memory reads on ESP32-C3. If Espressif could get it resolved, Live Variables will work on ESP32-C3 same way they do on ARM targets.

Visual Watch is a different mechanism. It allows plotting large arrays as graphs instead of just viewing them row-by-row. It requires the target to be stopped, just as the regular watch.

• This reply was modified 3 years, 6 months ago by support. Reason: added a link to the Github issue

[Author]

Posts