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

[support]

Hi,

The _WIN32 macro should not be defined with the Clang IntelliSense. If you believe it is, please double-check it with the following code:

#ifdef _WIN32
#error Oops
#endif

If you get the error message, please try selecting ‘go to definition’ for the WIN32 macro. Perhaps it is defined on one of your header files?

The __clang__ macro is defined together with the __GNUC__ macro; as Clang is normally backwards compatible with GCC, this should not be causing any trouble.

[support]

Hi,

Sorry for the confusion. In VisualGDB terminology, Embedded projects are the ones without any OS (i.e. barebone) that run on hardware like STM32. Linux projects involve the same setup/build steps for both Desktop and Embedded Linux, so they use the same Linux project wizard.

The “Exec format error” error means that your binary is not compatible with the target machine. E.g. you could have selected the normal x86 Linux toolchain instead of the ARM one or are trying to deploy the ARM binary on a Desktop machine instead.

Please double-check the selected toolchain and the target machine in your VisualGDB Project Properties.

[support]

Hi,

The value in the VisualGDB Project Properties is set for all configurations and is stored in stm32.props:

    <ItemDefinitionGroup>
        <ToolchainSettingsContainer>
            <ARMCPU>cortex-m4</ARMCPU>
            <InstructionSet>THUMB</InstructionSet>
            <FloatABI>soft</FloatABI>
        </ToolchainSettingsContainer>
    </ItemDefinitionGroup>

The corresponding VS property could override it for each configuration, but we do not recommend changing it manually to avoid confusion.

[support]

Hi,

If you are using the Custom edition or higher, you can click the “Convert to stand-alone project” button on the Embedded Project page of VisualGDB Project Properties.

This will automatically copy the relevant files under your project directory and update the references to them.

[support]

Hi,

We recommend installing the Windows build of Qt and then using Qt Designer from it to edit the .ui files. If you install the Qt VS add-in, it will automatically open the Qt designer once you click at a .ui file in Visual Studio.

[support]

Hi,

If the project relies on additional include directories, you need to specify them in your project properties (Project->VisualGDB Project Properties). With VisualGDB 5.2 it’s very simple, as it will search nearby directories for missing headers and suggest automatically adding discovered directories.

If this does not help, please let us know the errors you are encountering and we will suggest the related settings.

[support]

Hi,

The original ESP-IDF does not usually build out-of-the-box without adjusting several things manually. E.g. several different components inside it have include files with the same name and and hence expect different order of include directories.

We do have an open-source tool that converts the original ESP-IDF into a VisualGDB package, so you can try using it at your own risk: https://github.com/sysprogs/BSPTools/tree/master/generators/esp32

We have also just released an updated ESP32 toolchain that is based on the final ESP-IDF release (v1.0), so updating to it will automatically switch your projects to a newer ESP-IDF.

[support]

Hi,

VisualGDB normally does not prebuild the full IntelliSense information for all sources, as this takes a lot of space (a full uncompressed cache for the entire Linux Kernel is around 50GB) and normally if precompiled headers are detected properly, the delay you describe should not happen. It does build a highly optimized reference cache, but it’s only used in “Go to definition” and “Find all references” commands.

What we could offer is add a setting to forcibly precompile and include an arbitrary header file as if it was directly included from each source. Would that be helpful?

It also sounds like a good idea to measure how much time was spent compiling each header and offer such optimizations automatically, so we will experiment with this in v5.3.

 

[Author]

Posts