What is Included in Technical Support

VisualGDB is a productivity tool for engineers. It is designed to simplify common repetitive tasks, but it cannot automatically fix code or solve engineering problems: it's still up to the user to study the SDKs they are planning to use, read device datasheets, and have sufficient knowledge of C/C++. Our technical support goes along that line as well. If you encounter a problem that involves VisualGDB and some other components (e.g. ESP-IDF), we can help you understand how exactly VisualGDB interacts with them. If you would like us to troubleshoot the entire problem, untangle the internals of some external SDK, or figure out why a specific project is not building, we can give you a quote to do it as consulting, but we cannot offer it as a part of fixed-price product license.

Why such limits? Most projects break in their own unique way. Troubleshooting each one requires some time, and fixing one project does not automatically fix others. On the other hand, there's a finite number of spots where VisualGDB interacts with other tools, and if there is a bug in one of them, we can fix it for good, eliminating the problem for all of our users at once.

Common Examples

The rest of this page lists common problems encountered by VisualGDB users, and explains the scope of technical support in each case.

Project doesn't build

VisualGDB builds projects using the same compilers as virtually every other IDE: GCC, Keil or IAR. If the project doesn't build or doesn't work as expected, it usually means that some compiler flags are incorrect, or it includes some code that needs to be ported to a particular device or compiler. Because every project is unique, we cannot fix it for you without charging for the time spent on it. That said, we designed VisualGDB to make such troubleshooting as easy as possible:

  • Advanced CMake projects (including ESP-IDF) allow easily dumping build command lines (including all environment) into batch files. You can then compare it side-by-side with the command line from another working project, find the setting that is different, change it to verify that it works, and then update the project accordingly.
  • MSBuild projects store compiler command lines in .rsp files and can be configured to generate batch files as well. Once you got all command lines exported, you can use the same troubleshooting techniques as for CMake-based projects.

If you still need help, make sure you can build the same project using the same toolchain on the same computer outside VisualGDB, then export the build command line from VisualGDB, compare it to the working one, and adjust it to fix the problem. Once you narrow it down to a specific build argument, our support can help you find a VisualGDB setting that affects it, but it's up to you to find which argument is causing the problem.

Cannot debug an embedded device

VisualGDB's debugging functionality is built on top of external low-level tools (most commonly, OpenOCD). VisualGDB expects them to handle low-level communication (e.g. read memory contents) and builds high-level functionality (e.g. various plotting and tracing) on top of that. It usually just works out-of-the-box, however there are a number of reasons why it could not: faulty wiring, broken boards, inconsistent clock settings, disabling JTAG pins via firmware. Other problems are caused by selecting incompatible settings on the VisualGDB side. Our support can help you configure VisualGDB if you can get gdb-based debugging to work for the same project/device on the same machine. It typically involves finding an OpenOCD command line in the device documentation, running OpenOCD manually, connecting GDB to it and running the debug session manually: 

<architecture>-gdb.exe <ELF file>
target remote :<OpenOCD port>
load
break main
continue

If this setup works (you sucessfully trigger a breakpoint in main()), we can help you configure VisualGDB to match this setup. If not, it's up to you to figure out why the low-level debugging is not working.

Complex project stopped working

Changing settings in complex projects could sometimes cause very tricky problems. E.g. if your codebase has 2 versions of platform.h meant for different devices, accidentally changing the including path to the wrong one could cause all sorts of strange errors. Manually editing some tag in a .vcxproj file could work initially, but would then cause strange errors when you change another setting later. Because every project is unique, we will not know how to fix a specific one based on just the error message alone.

The easiest way to avoid such issues is to put the project under source control. If you encounter a strange error, try rolling back to the last working version, and carefully re-applying the last changes one-by-one. If you can find a specific setting that causes the problem, try changing it on another clean project created from scratch. If the problem persists, we should be able to help you. If the problem only happens on a particular project, you would need to compare it to the working one to narrow down the actual cause.

If you cannot roll back the latest changes, and do not know what exactly got changed, the troubleshooting steps would be more complex:

  1. Create a new project from scratch, using the same toolchain, same build system, and targeting same device. Make sure it works.
  2. Start merging the code from the old project to the new one. You can do it in parts, e.g.:
    • Use the .vgdbsettings file from the broken project on the working project. See if it breaks it.
    • Use the build settings (e.g. include directories) from the broken project on the "Hello, world" code from the working project. See if it triggers the problem.
    • Copy some properties from the broken .vcxproj file or CMake constructs from the broken CMakeLists.txt file. See if a particular property causes the issue.

Our support can help you locate a VisualGDB setting that corresponds to a particular MSBuild property or CMake construct, but it's up to you to find the one that is causing the problem.

Complete Repro Steps

When you report a VisualGDB problem, we try to reproduce it on our side as close as possible to your description. However, many problems are caused by fine details that are accidentally left out (e.g. space in a project path + using a particular toolchain that doesn't handle them well). If we cannot reproduce the problem based on the initial description, we would ask to provide complete repro steps:

  1. The steps should start with launching Visual Studio and creating a new project from scratch.
  2. The steps should include uncropped screenshots of every wizard page and every settings page where you change anything.
  3. The steps should not include opening or importing any external files, unless these files can also be created from scratch in reasonable time.

For simplicity, you can simply take screenshots of all the wizard pages and settings you change and paste them into a PDF file. Make sure you also include the relevant logs as text, so we can search them for known issues. You can also record a video showing the repro steps, and send us a link to it.