[support]

Hi,

Please enable Clang IntelliSense for your projects while analyzing the code coverage. The coverage highlighting overlays are a part of it and won’t work with the regular VC++ IntelliSense (you can quickly switch between the two via a button on the Clang IntelliSense Diagnostics Console).

You don’t need to enable the code coverage instrumentation (i.e. injection of coverage code into the compiled code) for the main project. Simply choose “no” when VisualGDB suggests doing it after you enable code coverage via VisualGDB Project Properties. This will keep the code uninstrumented, but will let VisualGDB look for coverage reports produced by the referenced library projects.

[support]

Sorry about that. We do actually test our example projects and they do work out-of-the-box. Perhaps you have modified the default settings in a way the causes conflicts?

Either way, if you could attach the screenshots of the wizard steps you go through in order to create the project, we can advise you on what is going on.

[support]

Thanks for updating your email address, we have linked it to your forum profile. It does, however, look like your support period has expired a while ago.

Please renew your license here and we will be happy to walk you through the relevant VisualGDB settings.

[support]

Yes, we will try to add something similar in one of the next major releases.

[support]

Hi,

The file might be a part of a static library. Normally checking the output in the View->Output window should help find the full path of the files with both definitions.

Alternatively please try disabling syscall implementations via the first page of VisualGDB Project Properties.

[support]

Hi,

Sorry about that, it indeed looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

Please replace the <Linux> section inside the %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.googletest\TestFramework.xml file with the following lines:

  <Linux>
    <AdditionalSourceFiles />
    <AdditionalHeaderFiles />
    <AdditionalPreprocessorMacros />
    <AdditionalLibraries>
      <string>pthread</string>
    </AdditionalLibraries>
    <InitializationLines>
      <string>testing::InitGoogleTest(&amp;argc, argv);</string>
      <string>return RUN_ALL_TESTS();</string>
    </InitializationLines>
    <AdvancedTestDiscoverers>
      <TestDiscoverer xsi:type="OutputBasedTestDiscoverer">
        <TargetDemangledNames>true</TargetDemangledNames>
        <CommandLineArguments>--gtest_list_tests</CommandLineArguments>
        <TestGroupRegex>^(|[^/]+/)([^ \t/]+)\.$</TestGroupRegex>
        <TestRegex>^[ \t]+([^ \t/]+)(|/[^ \t/]+)($| )</TestRegex>
        <UniqueNameFormat>{1}{2}_{4}{5}</UniqueNameFormat>
        <StructuredInternalNameFormat>{1}{2}.{4}{5}</StructuredInternalNameFormat>
        <UserFriendlyNameFormat>{1}{2}::{4}{5}</UserFriendlyNameFormat>
        <SecondaryIDFormat>{1}{2}::{4}{5}</SecondaryIDFormat>
        <ShortUserFriendlyNameFormat>{4}{5}</ShortUserFriendlyNameFormat>
        <LocationSymbolFormat>{2}_{4}_Test::TestBody()</LocationSymbolFormat>
      </TestDiscoverer>
    </AdvancedTestDiscoverers>
    <TestSelection xsi:type="ArgumentBasedTestSelection">
      <GlobalArgumentTemplate>--gtest_filter=$(PerTestArguments)</GlobalArgumentTemplate>
      <PerTestArgumentTemplate>$(1).$(2)</PerTestArgumentTemplate>
      <PerTestArgumentSeparator>:</PerTestArgumentSeparator>
      <TestIDRegex>(.*)::(.*)</TestIDRegex>
      <IDType>SecondaryID</IDType>
    </TestSelection>
    <TestReportChannel xsi:type="PipeBasedTestChannelWithEnv">
      <PipeTimestampVariableName>g_SysprogsTestReportTimestamp</PipeTimestampVariableName>
      <EnvironmentVariableName>SYSPROGS_TEST_REPORTING_PIPE</EnvironmentVariableName>
    </TestReportChannel>
  </Linux>

We will publish an official update to our googletest package after the next maintenance release (R2) in the next few days.

[support]

Hi,

Thanks  for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

[support]

Hi,

Sorry, the hardware registers window indeed only works when the target is stopped currently. We are planning to redesign it in the next major VisualGDB release, and this will also enable register updating while the target is running.

As a workaround, please try adding specific registers to Live Variables (the special Watch window that does get updated while the target is running). Let us know if you need more details on that and we will be happy to help.

[support]

Hi,

Could you have accidentally deleted the .vgdbsettings file mentioned in the error? Please try creating a new test project from scratch. Are you able to run the tests from it? Does switching the new project to the Release configuration (you would need to build the project after switching the configuration) result in an error again?

[support]

Hi,

It looks like your technical support has expired. Please renew it here and we will be happy to help you find the correct configuration.

[support]

Hi,

No problem. We have merged our patches into CMake 3.13.3 and updated our package. You can remove the %LOCALAPPDATA%\VisualGDB\CMake directory and restart Visual Studio. This should get CMake 3.13.3 installed instead of the previous version.

[support]

Sorry about that. Generally, based on our experience with Espressif’s tools, they are very sensitive to the specific toolchain/IDF versions. We had observed strange build-time and runtime errors after using a slightly different toolchain version that Espressif recommends, so we switched to picking up toolchain/IDF combinations recommended by Espressif, running minimal tests on them and shipping them in a way that can be seamlessly used with VisualGDB.

If Amazon is using a different version of the IDF, we would generally advise first importing it as an external embedded project with the toolchain tested by Amazon, using their OpenOCD build (manually configuring it via the “custom gdb stub”) and confirming that everything works. Then you could try replacing some of the components (e.g. OpenOCD) with the ones that come with VisualGDB.

We might be able to support this out-of-the-box once we see a considerable fraction of ESP32 users interested in this setup, however currently maintaining another stack of tools and a separate branch of the Advanced ESP-IDF Project Subsystem specifically for the Amazon FreeRTOS codebase is unfortunately more than we can offer, sorry.

[support]

Hi,

Thanks for the project link. It looks like the demo project is using a fairly old version of ESP-IDF that might not be compatible with the latest toolchain, or may not work reliably at all.

You can configure VisualGDB to use it by selecting the “import” option in the ESP-IDF selector on the first page of VisualGDB Project Properties. However, as it’s a relatively old ESP-IDF release, it may not work as expected and we would not advise doing that.

You can also import the project into VisualGDB as a regular external embedded project (see this tutorial). VisualGDB will then run the command line specified by you and will not make any assumptions about the project structure.

Generally, we would advise instead using the regular toolchain + ESP-IDF installed by VisualGDB and importing projects into this workflow. This will let you use the combinations of components that were tested together and will reduce the amount of errors you would have to resolve.

[support]

The Amazon FreeRTOS demo is likely ARM-specific, so you cannot directly import it “as is” into an ESP32-based project.

However you can create a regular project with ESP-IDF (see this tutorial) that will include a special port of FreeRTOS provided by Espressif. You can then call the regular FreeRTOS functions (same as called from the demo) from your main source file.

[support]

Hi,

ESP-IDF is already based on FreeRTOS, so no explicit action is required to use it – every project based on ESP-IDF includes a port of FreeRTOS.

[Author]

Posts