[support]

Hi,

It looks like when you go to the new line with VisualGDB, it inserts double indentation, so the logic that is supposed to remove it when ‘{‘ is typed, only removes a half of it.

It also looks like some other VS extension is highlighting the indentation in red color; perhaps the same extension is responsible for inserting extra spaces?

We have also added extra logging to this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.15.1912.msi

Please try re-running the case shown on Working2.gif and post the output of View->Clang IntelliSense Diagnostics Console here. It will explain what is going on.

[support]

Hi,

This happens because the newer gcc includes optimizations that make the libcompactcpp library unnecessary, so it was removed from the latest release. Please try opening VisualGDB Project Properties and clicking the regenerate button (it it’s not shown, try changing any of the MCU-related settings and restoring it back). This should rebuild all toolchain-specific settings and remove the references to the missing library.

[support]

Hi,

The behavior you are describing could be caused by several different factors:

• USB virtualization slowing down communication with the JTAG probe
• Some very frequently called functions being configured for monitoring, overloading the communication channel
• Unexpected RTOS modifications that cause internal state corruption (real-time watch only supports FreeRTOS currently)

The easiest way to diagnose this would be if you could make a short video showing:

• Your debug settings
• The slowly updating output you mentioned
• Several seconds of the live profiling window (including the ‘statistics’ view)
• Call stack and the context (e.g. the value of s_FastSemihostingState)

This should help us quickly understand what is going on and suggest a fix. If you don’t want to make the video public, you can simply send it via our support form.

Another approach would be to try running the analysis on a “LEDBlink” project and if works normally, start comparing/eliminating the differences between the 2 projects (e.g. switch to use same RTOS, same main() function, etc).

[support]

Hi,

Olimex recommends using the open-source avrdude program with AVR-ISP500. VisualGDB currently doesn’t support it out-of-the-box, so you would need to install and configure it manually. If you can confirm that the command-line programming with avrdude works, we can help you configure your VisualGDB project to run it automatically.

It could be also worth a try checking if the AVaRICE tool shipped with our AVR toolchain can recognize AVRISP MKII. If yes, you would not need to install any extra tools.

[support]

Hi,

Thanks for the exported settings. We have tried loading your settings into our VS2017 test setup, however we could not get the behavior you are demonstrating.

The incorrect formatting could be caused by interference from other plugins. Please try disabling all other extensions via Tools->Extensions and Updates and let us know if you locate a specific extension that causes this. If nothing helps, please try exporting all your Visual Studio settings and then resetting them to defaults.

[support]

Hi,

Sorry, it is hard to guess what is going on without knowing further details. Please try reproducing this on a smaller project and sending it to us so that we could examine it.

If the problem only happens on a larger project, please try comparing the settings between the 2 projects:

• .vgdbsettings files
• .vcxproj files (e.g. manually defined macros)
• sets of included headers

[support]

Hi,

Sorry for the confusion. We will try to explain how VisualGDB manages IntelliSense headers.

When you create your first project built on a remote Linux machine, VisualGDB creates a local Windows cache of the related header directories, so IntelliSense can parse them automatically. If you later install more packages to your Linux system, the headers installed by them won’t automatically be downloaded, leading in the error you are describing: the code would build, but IntelliSense would not find headers.

This could be fixed by letting VisualGDB rebuild the header directory cache. The exact wording of the command depends on your VisualGDB version and the project type, but the option is located on the IntelliSense Directories page of VisualGDB Project Properties (e.g. ‘Reload all directories’). If you are not sure, please attach a screenshot of that page and we will help you find the correct settings.

[support]

Thanks for trying it and sorry for the inconvenience. VisualGDB might be picking up the setting that causes this from the regular VC++ formatting settings.

Please try exporting them via Tools->Import and Export Settings -> Options->Text Editor->C/C++ and attach them here (or send them via our support page) so that we could try reproducing it on our side.

Another option would be to try exporting all settings and then resetting them. If this helps, please try exporting the settings after reset and comparing the produced files. This should show which settings were different and what setting was causing this.

[support]

Hi,

Please try synchronizing the header directories (via IntelliSense Settings page of VisualGDB Project Properties). This will ensure VisualGDB has access to the latest versions of all headers.

You can also try creating an advanced CMake project (requires VisualGDB 5.3) that will access the remote filesystem directly over SSH; this will eliminate the need to synchronize any headers or source files.

[support]

Hi,

You could work around this with a relatively simple hack: create a file called cplusplus.h in your project directory with the following contents:

#pragma once

#ifdef __cplusplus
    #undef __cplusplus
    #define __cplusplus <value>
#endif

then add the following code to your .vcxproj file:

  <ItemDefinitionGroup Condition="'$(DesignTimeBuild)' == 'true'">
    <ClCompile>
        <ForcedIncludeFiles>%(ClCompiler.ForcedIncludeFiles);cplusplus.h</ForcedIncludeFiles>
    </ClCompile>
  </ItemDefinitionGroup>

This will override the __cplusplus value used by IntelliSense, but won’t affect the actual build.

BTW, feel free to let us know the reasons you don’t like Clang IntelliSense. We are constantly improving it and adding new usability features, so we always appreciate feedback on making it even better.

[support]

Hi,

We understand your frustration with this, however it’s hard to guess what is going on based on the scarce puzzle pieces you provide. The behavior you are describing would be consistent with the ‘unix’ macro simply not being defined (which is the expected behavior for certain types of projects).

We would love to help you, but in order to do that, we need to understand your scenario and what you are trying to accomplish. So please provide the following information so that we can help you:

1. The exact steps to create the project (project type/toolchain/etc)
2. The steps to reproduce the problem, including the expected outcome and the observed outcome
3. A screenshot of the entire VS window showing the problem (often minor details like file names or the navigation bar provide important clues).

E.g. in our experiments the #ifdef unix looks like this:

The macro is not defined (and should not be for this project type), so the code inside #ifdef is grayed out and the code inside #ifndef is working as expected.

• This reply was modified 7 years, 8 months ago by support.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

We understand your frustration and agree that this is important, so we will try to give more context on this.

There are 2 popular low-level debug tools for modern ARM devices: OpenOCD and Segger J-Link.

• OpenOCD is free and works with many inexpensive debug probes like ST-Link, however it has some glitches and is not as user-friendly.
• Segger J-Link software requires a more expensive J-Link probe, but its low-level gdb stub is fully supported by the probe manufacturer, explicitly tested with many devices and is generally much more reliable.

With VisualGDB we don’t aim to replace any of those 2 low-level methods. Instead we build on top of them, focusing on usability features like easy project configuration, profiler, real-time watch, live variables, etc. We also provide easy setup GUI for OpenOCD that automatically detects and configures common setups, but this approach still inherits various glitches for advanced scenarios like the one you are encountering. We could address it by making a “bulletproof” fork of OpenOCD, however making it as reliable as J-Link would raise the product costs accordingly. Instead of doing that, we maintain out-of-the-box support for both debug methods and let our users choose between more reliable J-Link and free OpenOCD.

Hopefully this explains.

Thanks.

[support]

Hi,

No problem, we have submitted a ticket to the OpenOCD bugtracker: https://sourceforge.net/p/openocd/tickets/165/

[support]

Hi,

We have managed to reproduce the problem with the Eigen natvis file. It is caused by VisualGDB not supporting the $Tx syntax and the multi-dimensional ArrayItems.

We have added support for the $Tx syntax to the upcoming maintenance release, however we currently don’t have any plans for supporting multi-dimensional arrays. As a workaround we would advise creating a basic visualizer using our managed visualizer API described here. It allows using arbitrary logic for analyzing visualized expressions and would support multi-dimensional arrays as well.

[support]

Hi,

VS IntelliSense has its own logic for defining __cplusplus that is hard to control from the VisualGDB level. You could try overriding it by adding the following code to some common shared header:

#ifdef _MSC_VER
#define __cplusplus <value>
#endif

However this may cause strange IntelliSense errors as the VC++ IntelliSense is not 100% compatible with GCC-specific extensions. We generally recommend using Clang IntelliSense as it is specifically designed for better compatibility with GCC extensions.

[Author]

Posts