[support]

Hi,

Thanks for letting us know. This should normally work out-of-the-box, so it’s likely caused by interference from another plugin.

Please try disabling all other extensions via Extensions->Manage Extensions (or Tools->Extension Manager). If it doesn’t help, please check if the problem persists on a basic MinGW project created from scratch. If not, please try determining if there is any specific component (e.g. a specific toolchain or a specific global variable syntax) that is causing the trouble.

You can also check for suspicious output in View->Other Windows->VisualGDB Diagnostics Console. It may explain what is going on.

[support]

Hi,

Please see the following page for a detailed explanation on supported ESP-IDF versions: https://visualgdb.com/documentation/espidf/#troubleshooting

[support]

Yes, you can use the “Compare the current build to a specific version” button (see step #18 of the tutorial).

[support]

Thanks for sharing this. This is exactly the reason why we release the sources for our BSP-related tools.

[support]

Hi,

No problem. Indeed VisualGDB normally supports only one imported Atmel START SDK per device family (multiple SDKs for different devices can be imported at the same time).
We can show you how to override this by manually editing/moving the definition files, however it looks like your support period has recently expired.

Please renew it here and we will be happy to provide detailed instructions.

[support]

Hi,

Good to know it works. VisualGDB can indeed install a Python environment that was tested on our side with the nRFConnect SDK and should work out-of-the-box (see step #7 of our NRFConnect tutorial). In case of any Python-related problems, we suggest resetting the environment as shown on this page.

[support]

Hi,

VisualGDB actually provides its own mechanism for fast tracing – the advanced semihosting framework. You can reference it via VisualGDB Project Properties -> Embedded Frameworks and then use the regular printf()-like functions to output data. See this tutorial for a detailed example.

If you would like to specifically use SWO, you can configure it manually as shown here (use VisualGDB Project Properties -> Additional GDB Commands) and then use VisualGDB’s raw terminal to connect to the port where J-Link outputs the SWO data.

[support]

Hi,

Most likely, some setting between the projects is different (e.g. different toolchain, different libc type).

VisualGDB actually provides a convenient mechanism for troubleshooting this exact type of problem – differential view in Memory Explorer. Please follow this tutorial and you should be able to track down the differences.

[support]

No problem, please try this build: VisualGDB-5.5.7.3671.msi. It resolves the issue with the linker script and startup files.

In order to fix the problem with include directories and the FatFs folder, we would need to examine your project file (.cproject and .project) and also see the list of all source files in the project directory (obtained by running dir /s /b > list.txt). You can post it here, or send it to our support form.

If the project structure is confidential, you can also simply build our STM32CubeIDE project importer from source and adjust it on your side.

[support]

Hi,

VisualGDB does not use any special mechanism for Qt – it simply delegates the work to CMake, hence we do not have any special instructions for it.

Normally, CMake would pick it up automatically, as long as you resynchronize the sysroot via VisualGDB Project Properties -> Build Settings. If not, you may need to specify the CMAKE_PREFIX_PATH to point to the directory inside the toolchain where VisualGDB has copied the built Qt files.

You can set CMAKE_PREFIX_PATH via VisualGDB Project Properties -> CMake -> Extra Prefix Directories. If you are not sure about the exact value to set, please consider searching online for “qt cmake_prefix_path” for examples from Qt documentation and other discussions.

[support]

Hi,

Thanks for renewing your support. This might be indeed a bug in VisualGDB.

Please update to the latest VisualGDB 5.5 Preview 7. If this doesn’t fix the problem, please try creating a call stack of the crash as shown here and either post it here (along with the VisualGDB build number), or send it via our support form.

[support]

Hi,

Good to know it works. Generally, we advise relying on VisualGDB’s logic for installing the drivers, as we test it with many popular boards. Installing drivers manually always has a chance of breaking something accidentally.

[support]

Sorry, that would qualify as a technical support question and hence we would kindly ask you to renew your licenses, if you would like us to help resolving this.

If you do not wish to renew, please have a look through our documentation and tutorials. They may contain the answers to your questions.

[support]

Hi,

Based on the logs you attached, the exception is happening inside the VC++ project engine (Microsoft.VisualStudio.Project.VisualC.VCProjectEngine).

Most likely, Visual Studio has recently installed a minor update on both computers that started triggering the error. You can try reverting to the previous VS version and check if it resolves the problem, or alternatively report this to Microsoft support and see if they can fix it on their side.

Based on our experience, the ObjectDisposedException may occur sporadically inside the VC++ project engine, but reloading the solution while deleting the .vs folder often solves it. Either way, if you find this annoying, please consider using the Advanced CMake project subsystem (or other advanced project subsystems shown here). They are not based on the VC++ project type and won’t trigger this error.

Edit: If you suspect that the VisualGDB’s license checking logic is incorrect, we can temporarily extend the expiration date on your licenses in our system, and you can recheck if it changes anything.

[support]

Based on our experience, the pre-release ESP-IDF versions, such as v4.2, are extremely unreliable and can be difficult to configure. They also change the internal structure relatively often, so we do not support them until they reach the “release candidate” stage (see this page for a list of stable releases). You can try troubleshooting it at your own risk, but if it turns out not working, please follow the instructions from the second link we posted earlier to get to the latest stable version.

[Author]

Posts