[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.

[support]

Hi,

Sorry, the ST-Link debug probes only work with ARM devices and only via SWD. For ESP8266/ESP32 you would need something more low-level that supports JTAG. We recommend Olimex ARM-USB-OCD-H and have explicitly tested our ESP32 board with it.

[support]

Hi,

If the program runs successfully on the build server (x86 machine), this is an x86 executable and it won’t run on ARM.

In order to build Qt applications with a cross-toolchain, you need to get a special cross-compiled build of Qt (including a special version of Qmake) and specify it when creating the VisualGDB project. This is fairly complex, but we have detailed instructions on doing that with a Windows cross-compiler: http://visualgdb.com/tutorials/raspberry/qt/embedded/

We also offer a service of building custom toolchains, so we could build you a Windows toolchain with a cross-built Qt that will be 100% compatible with your target board if you don’t want to do this yourself. Simply contact our sales to get a quote on that.

[support]

Hi,

No problem. We have added a workaround for this behavior in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1343.msi

It should automatically set the file type for .S files in case VS did not recognize it properly.

[support]

You can remove the VisualGDB-supplied system file and other files via VisualGDB Project Properties -> Embedded Frameworks.

Simply uncheck the “STM32 HAL” and other similar ones and those files will be removed.

The ‘frame not in module’ problem happens when your program triggers an exception outside the known sources. Please check the Call Stack window to see what could be causing it.

If you are not sure, please set a breakpoint in the Reset_Handler function and step through your code to see at which point the error occurs.

[Author]

Posts