[support]

Hi,

Please refer to this page for a detailed overview of the Clang IntelliSense settings, and project types where it can be turned off.

[support]

Hi,

No problem, we have reproduced and fixed the issue with the component list. Please try updating to the latest CMake package via VisualGDB Package Manager.

We could not reproduce the issue with the headers though. Please try closing the solution, deleting the build and .visualgdb folders and reopening it again. If it doesn’t solve the problem, please try following the steps below to track it down:

1. Take a note of the specific source file that reports missing headers and a specific header file that is missing.
2. Locate the target containing that source file.
3. Locate the <project directory>\build\VisualGDB\Debug\.cmake\api\v1\reply\target-<ID>.json file corresponding to that target and make a backup of it.
4. Install the old CMake version manually. You can simply rename the file to .tgz and extract it to %LOCALAPPDATA%\VisualGDB\CMake.
5. Reload the project and confirm that the problem no longer occurs.
6. Locate the updated json file for the target.
7. Attach both json files (please put them into a .zip archive) and let us know the exact source file that triggers the error, the exact header file that is missing, and the directory where that header file is located when it’s found (when using the old CMake build). This should help us track it down and release a hotfix.

 

[support]

Thanks, it looks like the project file is using a slightly different way of specifying the linker script, that breaks our project importer.

Please try this build: VisualGDB-5.6.1.4131.msi

[support]

Hi,

Please see the following forum thread for more details: https://sysprogs.com/w/forums/topic/com-port-window-font-raw-terminal/

[support]

Hi,

Most likely, you are trying to import a project generated with an older version of  the STM32CubeIDE that specifies some settings differently. The easiest way to get it working would be to compare its .cproject file against one of the .cproject files that get imported successfully (e.g. from the STM32 SDKs), specifically looking for the com.st.stm32cube.ide.mcu.gnu.managedbuild.tool.c.linker.option.script option.

If it doesn’t help, please feel free to attach the .cproject file (please place it into a .zip archive if you would like to attach it here) and we will recheck why the STM32IDE importing plugin doesn’t work with it.

[support]

Thanks for renewing your support. Instrumenting the code for profiling could result in crashes if the original code was corrupting the memory, had possible race conditions or other implicit dependencies.

In order to troubleshoot it, please try the following:

1. Instead of using the Analyze command, try enabling real-time watch in VisualGDB Project Properties -> Dynamic Analysis, but don’t create any watches yet. Does this result in a crash?
2. If yes, please try changing the instrumentation settings on the Dynamic Analysis page to only instrument one or two functions (e.g. the one controlling the LED). Does the code still crash?
3. If instrumenting only one function stops the crashing, the problem is caused by instrumenting some of the low-level system functions. Please try excluding all low-level functions from being instrumented to see if it solves the problem.
4. If instrumenting only one function still causes crashing, please try reproducing the problem on a clean project created from scratch for the same device. Once you get it reproduced, please share the repro project with us and we will investigate it further.

[support]

Hi,

We normally advise using our CMake fork when building projects on the Windows side, as we routinely test various VisualGDB features with it. That said, you can configure VisualGDB to use a specific CMake executable via Tools->Options->VisualGDB->General->Tools->Full path to cmake.exe.

We have also updated our CMake fork based on the latest v3.20.3 release. You can update it via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Please let us know the exact names and full paths of the .hex files you located, so that we could recheck what is going on.

[support]

Hi,

This error would appear when VisualGDB could not find any zephyr.hex or merged.hex files in the build directory. Normally, they should be produced by the Zephyr build and are used by VisualGDB to include the softdevice into the ELF file that will be loaded into gdb.

Please try checking the C:\Embedded\Embedded\build\nrf52dk_nrf52832\Debug\zephyr directory for *.hex, *.bin and *.elf files.

If the hex file is not created, it could have been disabled via Zephyr settings. Please try checking if the problem persists with a freshly created project. If not, please try comparing the settings between the 2 projects and adjust the initial project accordingly.

[support]

No problem and good to know it works. It’s hard to say why it would get placed into the root folder – it could be a side effect of a specific combination of settings. If working around the problem by deleting the file works for you, no further action is necessary. If it becomes more annoying, or you suspect that there’s a bug in VisualGDB affecting the project layout, feel free to attach the repro steps and we will investigate it further.

[support]

Hi,

Unfortunately, it’s hard to suggest anything specific based on the description you provided. Please try reproducing the problem on a freshly created project. If it persists, please share the full steps to reproduce the issue from scratch, including all the relevant screenshots per our problem reporting guidelines.

[support]

Hi,

The newer builds usually include all the fixes from the older builds (unless they have been removed due to problems with other functionality), hence it should work.

The problems are likely caused by something else. Please feel free to share the details on the errors you get (and also renew your support here as it has recently expired) and we will help you get it working.

[support]

Hi,

It looks like you are using a relatively old preview build. Please try updating to the latest one: VisualGDB-5.6.1.4124.msi

[support]

Hi everyone,

Thanks, we confirm that VS 16.10 is missing one of the classes used by language services (such as Clang IntelliSense) to query information from Visual Studio using the backward-compatible COM interfaces. We are working on this and will release a hotfix in the next couple of hours.

Update: we have added a workaround to the issue to the following build: VisualGDB-5.6.1.4119.msi. We will also release hotfixes for VisualGDB 5.5 and VisualKernel 3.1 soon.

Update #2: we have also released VisualGDB 5.5R5 and VisualKernel 3.1R9 that include a fix to this issue. You can get them via the regular download pages if you do not want to install the beta.

• This reply was modified 4 years, 3 months ago by support.
• This reply was modified 4 years, 3 months ago by support.

[support]

Hi,

The STM32CubeMX tool indeed often generates somewhat broken code. Unfortunately, the exact behavior varies from version to version, and some configurations of settings indeed require manual adjustments.

Adding a brand new setting to cancel out automatically imported include directories could create unnecessary complexity (e.g. forgetting about that setting would make it look that the regular Include Directories setting got totally broken). Instead, we would advise simply patching the STM32CubeMX importing plugin. It is fully open-source, so you can simply modify it to exclude certain include directories that match a certain pattern (e.g. before the ApplyFreeRTOSFixes() method is called), and replace the version shipped with VisualGDB by the customized version.

If the behavior isn’t fixed on the ST side in a couple of months, please feel free to post an update here and we will recheck it and include a permanent fix for it on our side.

[Author]

Posts