[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 4 years, 5 months ago by support. Reason: added a link to the Github issue

[support]

Hi,

Sorry, we do not have a toolchain for the 64-bit Raspberry Pi OS. Please consider using a 32-bit Raspberry Pi OS instead, or simply try building the code directly on the target.

 

[support]

Hi,

You can try using an alternate payment processor by following the instructions below:

1. Go to the buy page, locate the edition you would like to purchase, right-click on the corresponding “Buy” button and select “Copy Link”
2. Add “&platform=avangate” to the checkout link copied in the previous step
3. Use the updated link (e.g. https://visualgdb.com/buy/checkout?edition=vgdb_max&platform=avangate) to proceed with the purchase

That said, depending on your location and international regulations, some payment methods may still not be supported. The most versatile payment method that works in every country we are aware of is a major credit card. If this is not an option, please consider finding a local reseller and purchasing through them.

[support]

No problem and good to know it works. We have also updated VisualGDB on our side to suggest the use of the IP address or port when trying to create an SSH connection to ‘localhost’.

[support]

Good to know it works. Also thanks for the suggestion, we will consider adding more checks to the installer in the next VisualGDB releases.

[support]

Thanks for the updated log file. Indeed, VisualGDB is saving the imported toolchain to the location normally used for the Windows toolchains:

Saving newly imported toolchain to C:\Users\709218\AppData\Local\VisualGDB\ToolchainProfiles\localhost\com.sysprogs.imported.arm-linux-gnueabihf-4.8.3__r0...

This happens because the project is configured to connect to localhost via the default SSH port, so VisualGDB treats it as a Linux machine name. In order to workaround it, please consider using “127.0.0.1” instead of “localhost”, or specifying the port explicitly, i.e. “localhost:22”.

That said, we normally advise picking the WSL distro directly in the host selector, rather than using SSH. It will enable the special WSL-specific communication mode, that is faster then SSH.

[support]

Thanks for the screenshot. This VisualGDB build uses the new installation logic that first checks the v170 folder, and if it’s absent – falls back to the v160 folder. Perhaps when you installed VisualGDB, your Visual Studio had the v160 as a leftover from the VS Preview, and the v170 was completely missing (e.g. VC++ workload was not installed)?

Either way, you can try uninstalling VisualGDB completely and installing it again. If the v170 folder is present, VisualGDB should recognize it.

[Author]

Posts