[support]

Hi,

Looks like Espressif has changed the internal structure of the config definitions again. We have updated VisualGDB to handle the new structure in this build [VisualGDB-5.5.7.3679.msi].

That said, ESP-IDF 4.1 is still a pre-release, so it may change again. If you would like to avoid disruptions to your workflow, please consider waiting until it becomes a stable release use the version that we will ship with our toolchain (it will be tested for compatibility and should work out-of-the-box).

[support]

Sorry, we do not have any special GUI for comparing two external projects.

Regarding the differences, it’s hard to say why the numbers would not add up. The difference could be coming from other source files, or library functions that are not associated with any particular source file.

[support]

Hi,

Thanks for reporting this. We have just released an updated version of the STM32 BSP that defines the FPU for all the devices correctly. You can install it via Tools->VisualGDB->Manage VisualGDB Packages.

If you still need help overriding the settings, please let us know.

[support]

Thanks for the detailed repro example. We have reproduced the problem and fixed it in the following build: VisualGDB-5.5.7.3678.msi

[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.

[Author]

Posts