[support]

Hi,

Good to know that moving VisualGDBCache worked. We are planning to restructure the VisualGDB’s temporary directory paths similarly to what VS does (e.g. .visualgdb\cache, .visualgdb\CodeDB, etc.) in the final VisualGDB 5.5. Based on the current estimates, we will release a preview build using the new structure in the next 2-4 weeks.

It this won’t work, we can add a project-level setting that will allow moving the CodeDB directory by manually changing an element in the .vgdbpsettings/.vgbdproj file.

[support]

Hi,

Thanks for pointing this out. Indeed, the command used by OpenOCD to specify the frequency has recently changed and the projects created earlier would still use the old command.

We have released another update to OpenOCD that automatically substitutes the old command with the new one. Please feel free to update it via VisualGDB Package Manager and it will work out-of-the-box.

[support]

Hi,

Normally, VisualGDB would automatically pick up the deployed file paths, however some projects might be structured in a way that prevents CMake from reporting the correct .so file path to VisualGDB. Please also make sure you are using VisualGDB 5.5 Preview 4, since it includes special checks that normally find and deploy the  .so.<version> files automatically.

You can double-check what exactly gets deployed via VisualGDB Project Properties -> Debug Settings -> Verify Deployment Settings.

If you are using the Custom edition or higher, you can use VisualGDB Project Properties -> Custom Debug Steps to deploy arbitrary files before debugging. For lower editions, we would advise experimenting with CMake definition of the libraspicam.so target (e.g. removing the version specifier) to make sure the library path reported by CMake (shown via Verify Deployment Settings) matches the name referenced by the main project.

[support]

Hi,

Please make sure you use the latest VisualGDB 5.5 Preview 4. It will install CMake automatically. If it doesn’t happen, please share a screenshot of the About VisualGDB window and the first page of the VisualGDB Project Properties window for your project and we will advise on the steps to get this working.

[support]

Hi,

This looks like the target might be configured to drop the SSH connections after some inactivity time. Normally, VisualGDB would automatically reconnect to the target, however for some types of custom actions that would not work. If this is the case, setting the keep-alive packet period to about 1 minute in Tools->VisualGDB->Manage SSH Connections should fully work around the problem.

[support]

Hi,

This looks like a bug in OpenOCD. Please consider building it from sources as shown in this tutorial and stepping through the FLASH programming logic to pinpoint the problem.

Alternatively, please try using Segger J-Link instead. It comes with its own GDB stub that is more reliable than OpenOCD and is fully supported by Segger.

[support]

Hi,

If you have accidentally deleted the file built by the project, please try building the project again using the regular Visual Studio’s Build All/Rebuild All command.

[support]

Thanks, looks like you are using an MSBuild-based project.
Please refer to the following tutorial for an example on enabling the map files: https://visualgdb.com/tutorials/arm/linkerscripts/

[support]

Hi,

According to our records, your support period has expired. In order to continue receiving support, please renew your key here: https://sysprogs.com/splm/mykey

[support]

No problem, we have investigated this and released another update. Please update your OpenOCD package via the VisualGDB Package Manager.

[support]

Hi,

No problem, looks like the upstream OpenOCD has renamed some JTAG-related commands and some of the scripts shipped with our OpenOCD build were not updated.

We have fixed the issue. Please try reinstalling the OpenOCD release via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

Please see the following page for a detailed explanation: https://visualgdb.com/support/idfcheckout/

Edit: VisualGDB 5.5 Preview 5 now fully supports ESP-IDF 4.1. Simply install it over any other VisualGDB version and get our latest ESP32 toolchain and you will be able to install ESP-IDF 4.1 into it:

• This reply was modified 5 years, 3 months ago by support. Reason: Mentioned new ESP-IDF 4.1 support

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This is already supported via VisualGDB Project Properties -> Debug Settings -> Full-Custom Mode.

Simply specify “–interpreter mi $(TargetPath)” in the gdb arguments and use the “target remote <host>:<port>” as the target selection command. This will connect gdb to a remote target.

You can also automate running the remote OpenOCD instance via the Custom Debug Steps page of VisualGDB Project Properties.

[support]

Sorry, it is not possible for us to provide the exact configuration steps for 3rd-party frameworks and tools, unless it is something extremely common (i.e. relevant to a huge amount of users) and worth supporting out-of-the-box and having a separate tutorial.

We can do the necessary research and publish a detailed tutorial as a part of our paid consulting program (please contact our sales for pricing). Alternatively, we can help you understand the VisualGDB side of the setup. E.g. if you manage to setup the project manually and find the correct compiler command lines and file layout, we can help you setup VisualGDB to replicate the manual setup results.

[support]

This sounds very similar to what is already supported with the VisualGDB project templates.
We actually have a huge collection of tutorials showing various VisualGDB features here: https://visualgdb.com/tutorials/

You can find the one showing the project templates by searching for “templates” on the tutorial list page.

Please also feel free to look through other tutorials for ideas on further improving your productivity with VisualGDB.

[Author]

Posts