[support]

You can view the status of your support, manage your renewals and upgrades here: https://sysprogs.com/splm/mykey

[support]

If you you would like us to point out exact troubleshooting steps, we would kindly ask you to renew your support. Otherwise, you can just try googling it. We have a lot of documentation describing various troubleshooting scenarios.

[support]

This sounds like you have accidentally broken something while trying to uninstall/reinstall (edited some files?). It doesn’t sound like any known issue. It could be that the older VisualGDB is not compatible with your Visual Studio or some other part of your setup.

Normally, completely uninstalling VisualGDB, Visual Studio, deleting all directories and reinstalling everything back should help.

 

[support]

Hi,

You can do that by selecting a range of data on the graph, right-clicking on it and selecting “Export selected data”. This will limit the CSV file to just the selected range.

[support]

Hi,

That’s beyond us as well. The latest ESP32 Arduino package indeed includes some rather long paths. They seemingly come from some 3rd-party code that Espressif bundled with their package and don’t seem to be actively used (unless you specifically want to include some connectedhomeip headers).

We looked into it earlier when the same package was causing other issues, and it turned out that Arduino IDE just silently ignores the long paths. So, we updated VisualGDB to show the list of the files it could not install, but otherwise do what the Arduino IDE does. If you don’t need these headers, you can just ignore the warning and go ahead. Otherwise, you can try convincing Espressif to move the affected folders within their package, because they would not work on Windows regardless of the used IDE.

[support]

Every Linux target needs its own cross-toolchain specially built for it. There is no universal toolchain that will work for all targets. We can give you a quote for building a toolchain for you, or you can check with the target vendor if there is a ready-to-use toolchain.

[support]

Hi,

The riscv64-unknown-elf-cpp toolchain is meant for barebone targets (i.e. without OS) and may not work with Linux systems. You can force VisualGDB to use it by deleting the toolchain.xml file and re-importing it manually by pointing at the gdb executable, but it will likely not work correctly with the Linux target.

[support]

Hi,

There is no direct mapping of registry keys into VisualGDB parameters, however you can use custom per-user variables (see this page) or define it via a system-level environment variable, and just reference it using the regular variable syntax.

[support]

Hi,

Good to know it’s starting to work.

Running GDB locally would be happening if you did not enable the “Allow choosing build/clean/debug command hosts independently” checkbox in VisualGDB Project Properties -> Linux Project. If it is set, you would need to double-check the host configured in the GDB command selector.

VisualGDB passes -v to killall so that it could log errors reported by it. We’ll monitor feedback from other users and will consider adding an option to disable it if it causes trouble on other systems. As a workaround, running killall as a custom pre-debug step should work just fine.

[support]

Please try creating a new project using the wizard. It should initialize the Python environment correctly.

[support]

Hi,

The easiest way to get it working would be using Quick Debug. Once VisualGDB encounters mismatching file paths, it will show special GUI for locating them on your machine, and will guide you through setting up the path mappings.

You can disable the FLASH loading during Quick Debug by manually removing “load” from the startup commands in the Advanced view of the debug method.

[support]

OK, we have rechecked it. VisualGDB should normally handle it correctly. You can try opening View->Other Windows->VisualGDB Diagnostics, initiating a FLASH programming and checking that the diagnostics console mentions as 1200 bps reset sequence on the correct COM port.

If VisualGDB does mention the reset, but the board does not accept it, the best we can do is share the code snippet on our side that is responsible for resetting the board:

using (var port = new System.IO.Ports.SerialPort(COMPortFromSettings) { BaudRate = 1200 })
{
    port.Open();
    port.RtsEnable = true;
    port.DtrEnable = true;
    port.Handshake = System.IO.Ports.Handshake.RequestToSend;
    Thread.Sleep(1000);
    port.DtrEnable = false;
    port.Close();
}

If you can tweak it to the point where the board can recognize it, we can add a setting on our side to replicate it. Otherwise, you would need to use an oscilloscope/logic analyzer on the COM port pins to figure out the exact difference between the Arduino IDE and our reset implementation. It could boil down to timings on a particular board and a particular COM port, and may just not be worth the effort if it only affects one board.

[support]

This could be tricky. The 1200bps touch indeed isn’t documented very well. VisualGDB does support it for some ESP8266 targets, however the Arduino Uno could be handling it differently.

We are currently fixing a few last-minute issues with the upcoming VisualGDB 6.0R7 and will look into this after that.

[support]

Hi,

No problem. If you only want to override file transfers, it could be easier to disable deployment and source uploads on the VisualGDB level, figure out command-line tools that would do the deployment (ftp client?) and just run custom pre-build or pre-debug commands invoking those tools.

With multiple targets, VisualGDB does support overriding the debug settings, however it only works when letting VisualGDB manage configurations and platforms. If you are using CMake presets, VisualGDB assumes that they can be changed at any moment outside VisualGDB, and tries to minimize dependencies on them. That said, you can try using Debugger Setups. The only difference is that you would need to pick a setup via the VisualGDB toolbar separately from picking the build preset.

[support]

Hi,

No problem, please try this build: VisualGDB-6.0.107.5304.msi. It should fix the issues #1 and #4.

You can override the GDB server command line by switching the debug mode to Custom GDB Stub (VisualGDB Project Properties -> Debug Settings) and specifying the gdbserver command line manually.

The SSH issues are trickier, but not unsolvable. One option would be to use the custom transport interfaces to define your own transport using FTP, Telnet or anything else. VisualGDB will delegate the low-level tasks like running commands to it, so you can ensure it only uses the interfaces supported by your target. Another option would be to patch libssh2 to work with your target, and emulate missing commands like stat. Our fork of libssh2 is published here; you can build a debug version and investigate why it is crashing.

 

[Author]

Posts