[support]

Hi,

Our Clang IntelliSense uses Clang 6.0 that supports many of the C++20 features. That said, since it uses the headers directly from your toolchain, the toolchain must support C++20 as well and it should be selected via the “language standard” setting in project properties, as many toolchains default to a lower C++ language standard version.

[support]

Hi,

Please try creating a new MSBuild-based project using the VisualGDB project wizard corresponding to your project type. If the newly created project works, please try comparing the .vcxproj files of the old vs. new project.

If you find multiple differences, you can try eliminating them one-by-one by manually editing the files. Once you find a difference that is causing the issues, you can manually apply it to the old files.

[support]

No problem. Feel free to bump this thread once ESP-IDF v5 is officially released (not beta) and we will provide a timeline on fully integrating it.

[support]

Indeed, since Visual Assist relies on the regular VC++ IntelliSense engine, it won’t work with the projects using Clang IntelliSense. And disabling Clang IntelliSense naturally disables all features provided by it, such as Code Explorer.

That said, if you miss specific functionality from VisualAssist that is not provided by the Clang IntelliSense, feel free to use let us know. We might be able to add it to one of the future versions of VisualGDB.

[support]

Thanks, we have confirmed the issue and found the root cause. The latest nRF52 Arduino package changed the OpenOCD command template to a format that was not supported by VisualGDB:

tools.openocd.upload.pattern="{path}/{cmd}" -s "{path}/share/openocd/scripts/" -f "{runtime.platform.path}/variants/{build.variant}/{build.openocdscript}" -c "program {{{build.path}/{build.project_name}-merged.hex}} verify reset exit"

The extra {{}} after the ‘program’ argument intended to pass the literal ‘{‘ and ‘}’ to OpenOCD was not properly translated.

We have updated VisualGDB to handle this correctly. Please try this build: VisualGDB-5.6.108.4712.msi

[support]

Hi,

Please refer to the following page for more details and troubleshooting instructions: https://visualgdb.com/documentation/colors/

[support]

Hi,

This looks like some part of the project settings got corrupt, although it’s hard to tell anything specific without knowing more context of the issue.

Please try reverting the project to the last version that worked. If you can then point out a specific setting that triggers the issue, we can gladly release a hotfix for it, or suggest a workaround.

[support]

Hi,

The steps you provided involve importing a 3rd-party project. If you would like to get it working with VisualGDB, please make sure you can build it by running CMake/Ninja manually on the same machine using the same toolchain. If the project doesn’t build/work on your platform, it may need to be ported to it and VisualGDB cannot do it automatically.

Once you get the manual build to work, please share:

1. The manual CMake command line that produces a successful build
2. CMake command line from the VisualGDB build log

We can then help you adjust the VisualGDB settings to match the manual build command line that works.

• This reply was modified 2 years, 10 months ago by support.

[support]

Hi,

The KGDBoE module relies on several APIs that slightly vary between different kernel versions (distro-specific patches make this even harder). You can try using the latest KGDBoE version from our repository – it works out-of-the-box with Ubuntu 22.04.

That said, if you are new to Linux kernel development and do not wish to troubleshoot KGDBoE compatibility issues, we would advise using one of the supported virtual machine types with the VM-specific debugging interface. As the VM-based debugger runs outside of the kernel, it doesn’t need any special adjustment and usually just works out-of-the-box.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

We will monitor replies on this thread. If sufficient users with active licenses post that they are interested in GD32 devices, we will consider supporting them directly. If anyone agrees to cover the research and testing costs directly, we will also be happy to do it.

If your project depends on the GD32 devices, yet ordering a custom BSP from us does not make economic sense, you are welcome to do the research on your side and setup a project manually. The rest of the VisualGDB functionality will work just fine.

[support]

Hi,

This looks like more of a generic CMake question than something specific to VisualGDB. Feel free to post it on CMake forums, if you get a CMake-specific advice, we can help you map it to particular VisualGDB settings. You can also dump the CMake command line used by VisualGDB to a batch file as shown here, and experiment by modifying the CMake command line directly instead of going through various VisualGDB settings. If you find a command line that works better, we can help you find VisualGDB settings that will replicate it.

The CMake files shown in Solution Explorer (including multiple instances of toolchain.cmake) are reported by CMake via the cmakeFiles-v1-<ID>.json files. The one used by VisualGDB should have the path of C:\Users\ XXX \libjpeg-turbo-2.1.4\./build/VisualGDB/Debug/toolchain.cmake. You can try using our CMake debugger to find out which file references the second one.

[support]

You are always welcome to create a project manually by following this tutorial.  This will work for any device type that has a compatible GCC toolchain and is not directly supported by VisualGDB.

We can also create an out-of-the-box BSP if sufficient users with active licenses confirm their interest in this device family, or if anyone agrees to directly cover the research and testing costs, as we do for other niche devices.

[support]

Sorry about that, it’s indeed a bug introduced by another fix in v5.6R7. We have fixed it in the following build: VisualGDB-5.6.107.4696.msi

[support]

Thanks for the detailed screenshots, we would have never guessed what you were trying to do otherwise.

Below is the explanation of what is going on:

1. Renaming the configuration from Debug to Renamed and not changing the build type changes the CMake command line issued by VisualGDB from -DCMAKE_BUILD_TYPE=DEBUG to -DCMAKE_BUILD_TYPE=RENAMED.
2. CMake does not know the RENAMED build type, so it never passes the debug-specific arguments to GCC.
3. In step 6 (08.jpg) you override the debug information format for the executable only (not the STM32CubeMX libraries). This happens because you do it via the properties for the executable (node with the console icon in Solution Explorer).

The workaround is extremely easy though: simply set the CMake build type to DEBUG for the renamed configuration, and it will automatically get the correct flags:

You can also proceed with your own custom build type (in case you need it for any reason) by adding the following lines to CMakeLists.txt:

set(CMAKE_C_FLAGS_RENAMED ${CMAKE_C_FLAGS_DEBUG})
set(CMAKE_CXX_FLAGS_RENAMED ${CMAKE_CXX_FLAGS_DEBUG})

That said, we would advise using the classical CMake build types (Debug/Release/RelWithDebInfo) and manually passing additional definitions to CMake if you need different configurations to produce different outputs.

Attachments:

You must be logged in to view attached files.

[Author]

Posts