Forum Replies Created
-
Posts
-
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Hi,
Sorry for the delayed reply.
The Digi tutorial is very old and does not reflect the new simplified project wizards.
Most likely you don’t need to use the Custom wizard at all – if your toolchain consists of the regular tools like gcc, ld and make, you can simply select it in the VisualGDB project wizard and VisualGDB will setup a basic project automatically including the necessary deployment steps (see this tutorial: http://visualgdb.com/tutorials/linux/3machine/).
If you want to configure manual build steps nonetheless, you can change the build machine (where gcc and other tools are located) globally on the Project Settings page.
If you encounter any further problems, please feel free to let us know and we will help.
Hi,
The error message should normally contain the gcc output. Does it show any details about the problem?
If not, please try running gcc manually with the flags shown in the error message. Sometimes gcc fails to start due to missing DLL files and only shows a meaningful error message if started manually from cmd.exe or Explorer.
