[support]

Hi,

If you are getting build errors, most likely the toolchain got corrupt, so removing and reinstalling it should help.

FLASH reading errors are tougher and could indicate a dead chip. During our tests with ESP8266 three different boards routinely died under different circumstances, so we would suggest simply getting another one.

[support]

Hi,

Please follow this tutorial: http://visualgdb.com/tutorials/arm/legacy/

[support]

Hi,

The VisualGDB packages are saved for each user independently (under %LOCALAPPDATA%\VisualGDB). If you have downloaded them to a different user, you can simply copy the contents of that folder to your current user account and VisualGDB will recognize those packages automatically.

[support]

Hi,

We have encountered this problem while testing our BSP and it is normally resolved by adding ‘LWIP_TIMEVAL_PRIVATE=0’ to the preprocessor macro list.

VisualGDB should do this automatically when you create a new lwIP-based project. If this does not happen, please let us know.

[support]

Hi,

Thanks for confirming this. We have quickly rechecked the ‘Save host key’ dialog, but could not get it to appear behind VS.

Could you please let us know the exact steps that cause this behavior on your machine? (you can rename the %APPDATA%\VisualGDB\KnownHosts.xml file to temporarily reset the saved keys).

[support]

Hi,

This looks like a VisualGDB bug, thanks for reporting it. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1349.msi

[support]

Hi,

Yes, the unit tests are available starting from the Custom edition.

If you don’t have it, you can easily upgrade your current license here: https://sysprogs.com/splm/mykey

[support]

Hi,

VisualGDB processes the included files together with the source, however if you have non-Clang projects in your solution and open a header file that does not belong to a Clang-based project, VisualGDB will treat this header file as a part of a different project and won’t use the Clang engine for it.

Could you try right-clicking in that header file and check if the “Preprocess selected lines” or the “Generate a graph of include files” command is shown? If you are not sure, you can simply attach a screenshot showing the context menu in that file. This should help us understand what is causing this and suggest a workaround.

[support]

Hi,

Thanks for clarifying this, this would indeed interfere with the ‘out-of-the-box’ experience. The only workaround we could suggest is to download the package catalog manually, get the test framework archive and install it via Tools->VisualGDB Package Manager->Install Package from File.

[support]

Hi,

Good to know it works.

Regarding the memory window, VisualGDB normally only queries the region of memory that fits in the current window. Reducing the memory window height will reduce the amount of queried data. You can also try switching to the live memory engine (lightning icon in the toolbar) to improve the memory read speed. Also if you are using a VM with USB virtualization, it could significantly reduce debugging performance, so we would recommend moving it to a physical machine.

If you believe the memory window is still slow, please let us know and we will consider optimizing it further.

[support]

Hi,

Could it be that this specific header file is not a part of a VisualGDB project and hence instead of using Clang IntelliSense, Visual Studio opens it with the regular IntelliSense?

You could quickly check this by checking the blue ‘go’ button on top of the source file. If it is not shown, the file is not handled by the Clang IntelliSense. If this is the case, please let us know how you navigate to that file and we will try to fix this.

[support]

Hi,

Normally VisualGDB should download everything automatically. However, if your firewall is blocking the Internet connection for Visual Studio, VisualGDB won’t be able to do that.

You can check the connection explicitly by opening Tools->VisualGDB Package Manager and going to the ‘Online’ section.

[support]

Hi,

Please find the answers to your questions below:

1. The FreeRTOS package is normally a part of the BSP for your devices (e.g. STM32). You can reinstall any of those BSPs via Tools->VisualGDB Package Manager.
2. We always ship the FreeRTOS version that is included in the driver packages from ST. Once ST updates their packages to FreeRTOS 9.0.0, we will update our package as well.
3. You can simply remove the reference to the FreeRTOS shipped with VisualGDB and then manually add the files from your FreeRTOS checkout (and the include directories) to the project. This will probably require some minor adjustments (e.g. the configuration file and some macros).

If you want to figure out what is overwriting your IVT, we would recommend using a hardware breakpoint (Debug->Windows->Breakpoints->Add->Data Breakpoint). As soon as the CPU tries to modify the corresponding memory range, it will trigger and you will see the code responsible for it.

[support]

Hi,

You can try patching the <VisualGDB>\MSBuild\embedded.targets file (see the ChangeExtension part below):

  <Target Name="GenerateHexFile" DependsOnTargets="Link" Condition="'$(GenerateHexFile)' == 'true' and '$(GNUTargetType)' == 'Application'">
    <GenericGNUTool Sources = "$(TargetPath)"
            ToolPath="$(GNUToolchainBinaryDirectory)"
            ToolchainPrefix="$(GNUToolchainPrefix)"
            ExtraPath="$(GNUToolchainExtraPath)"
            VisualGDBSettingsFile="$(VisualGDBSettingsFile)"
            ToolExeNameBase="objcopy"
            ResponseFileTag="mkihex"
            RepeatForEachSource="true"
            PrimaryOutput="$([System.IO.Path]::ChangeExtension($(TargetPath),'ihex'))"
            FastUpToDateCheckDatabaseFile="$(FastUpToDateCheckDatabaseFile)"
            RemoteBuildMakefile="$(RemoteBuildMakefile)"
            CommandFormat="-O ihex $&lt; $@"/>
  </Target>

[support]

Hi,

We have tested it with ESP8266, but not explicitly with ESP32. So normally it should work, but we would not give a 100% guarantee on that.

[Author]

Posts