What is Included in Technical Support

VisualGDB support is intended to solve 2 types of problems:

  • Help our users find the relevant VisualGDB settings or features bring them the best productivity
  • Fix bugs in VisualGDB (or provide workarounds) when it's not working as intended

Because VisualGDB works together with many other components (compilers, frameworks, sample projects from device vendors, JTAG device drivers, etc.), it is sometimes hard to tell whether an issue is caused by VisualGDB or by some other component. In order to determine whether an issue is covered by the VisualGDB support, we use the steps below:

  • If you are asking how to configure VisualGDB to solve a problem, make sure you know how to solve the same problem using any other common IDE or command-line tools. E.g.:
    • "How do I specify include directories for a CMake project?" is covered by VisualGDB support. We will point you to the relevant documentation.
    • "How do I get the STM32 timer to run from the internal oscillator?" is not covered by VisualGDB support, because it is not VisualGDB-specific. You would need to change the code in the same way, as if you were using a different IDE.
    If you are new to C++ or a specific device family, you are welcome to use VisualGDB to explore the sample projects from different sources, however our support will not be able to explain their internals or adjust them to your needs.
  • If you have encountered a problem involving VisualGDB, please make sure it is specific to VisualGDB:
    • If the problem involves a build error, make sure the same project can be built with the same toolchain outside VisualGDB. If not, please fix it in the command-line build first. Our support can help you replicate the successful build result with VisualGDB, but it won't help porting the project to a different compiler or device.
    • If your JTAG debugger is not working with a particular device (or the device is behaving in a strange way), make sure the same doesn't happen when running OpenOCD or other debugging tools directly. If the problem persists outside VisualGDB, it is not caused by VisualGDB and is not covered by VisualGDB support.

How to Simplify Problem Descriptions

If you encounter a strange error that only happens in a certain complex environment, follow the steps below to simplify it:

  1. Create a project of the similar type from scratch. Try to use the default settings or follow one of our tutorials as close as possible.
  2. If the project doesn't build from scratch, your toolchain or other tools might be corrupt. Try reinstalling them via Tools->VisualGDB->Manage VisualGDB Packages.
  3. If the issue doesn't happen with the newly created project, try comparing the settings files between the 2 projects, and moving the settings one half at a time.
  4. Once you identify the exact setting that causes the problem, please provide us with a brief description, and we will fix it or help you find a workaround.

The Complete Repro Steps

If we cannot reproduce the problem based on the brief description, we would ask you to provide the complete repro steps.

  • The steps should begin with starting Visual Studio and show every step you take to create a project
  • Every step should be accompanied by a full uncropped screenshot.
  • 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.

Trying Multiple New Things at Once

The most common mistake made by users coming from other backgrounds (e.g. C# or Win32) is to skip the basic tutorials with a new device and go straight to creating a project with advanced functionality. It typically involves doing multiple things differently from the tutorial, and each change has a small chance of confusing some setting or combining together incompatible components. Once multiple things start breaking, users would try a few intuitive edits to troubleshoot things (often, breaking them further), and would then submit a support ticket showing a rather unique error message coming somewhere from the internals of ESP-IDF or mbed, expecting that we know exactly how to solve it.

Unfortunately, this is isn't the case. If you get strange errors from ESP-IDF, Python, NRFConnect or mbed, there is usually no easy fix. Multiple things have gone wrong and the easiest way to untangle it is to re-create everything from scratch:

  1. Try deleting all toolchains, BSPs and frameworks via Tools->VisualGDB->Manage VisualGDB Packages.
  2. Try resetting the Python path via Tools->Options->VisualGDB->General->Tools->Python directory.
  3. Delete the contents of the %LOCALAPPDATA%\VisualGDB directory
  4. Try installing our latest toolchain and the latest BSP and create a new most basic project (LEDBlink) from scratch.
  5. Do not point VisualGDB to any existing code or tools. Let it download a Python package, a CMake package

We do test our toolchains and BSPs before releasing them, so if you do not mix them with external components, they will work out-of-the-box.

Once you get the most basic example working, you can move up to the more complicated setups, but keep changing one thing at a time.

E.g., you want to get a bootloader working on nRF52. You found a tutorial that shows it for STM32. The most safe way to accomplish it would be to:

  1. Follow the STM32 bootloader tutorial exactly as shown (if you don't have the hardware, just make sure the project builds). Save the oprojecfor future reference.
  2. Follow the basic nRF52 tutorial. Make sure you can build and debug the project. Save it for future reference.
  3. Try editing the basic project to port the bootloader functionality. Make frequent backups or git commits. If it stops building at some point, you can always revert to the previous version.
  4. If some specific change starts causing errors (e.g. 'undefined symbol'), check the STM32 project for reference. See where that symbol is defined there. Think how to port it to nRF52.

This is an iterative process and it does take time, but this is the only way to get things done reliably. Our support is not intended to replace it. If you try quickly combining parts from different projects and submit a ticket when it doesn't work, we will ask you to follow the process above and will only help if VisualGDB itself is not working as shown in the tutorials (when using the same device as in the tutorial).

If you believe the problem you are encountering is caused by VisualGDB, we will ask you to provide the complete repro steps, showing what exactly you are doing. We will not be able to help based on a few isolated screenshots of error messages - they are not sufficient to see what is different between the reference setup on our side, and the broken setup on your side.

If you need help combining different projects or porting code to a new platform, we can gladly offer our consulting services, but as such help is highly project-specific, it is not included in our technical support.