Forum Replies Created
-
Posts
-
Hi,
The easiest way would be to upload the file to DropBox or other file sharing service and send us a link via our support form.
Hi,
We don’t offer any live support within our regular pricing, but you can submit the screenshots via our support page. We usually respond with detailed instructions within 24-48 hours.
Hi,
Good to know it works now. In case anyone else runs into the same problem, this usually happens when the build actually does not succeed and the main executable is not created.
Hi,
This could be caused by optimization. Please enure you have the “-O0” flag in the project settings.
You can diagnose this by injecting asm(“nop”) statements in the code and trying to set breakpoints there.
If your board is controlling a motor, it could make the power supply unstable and cause weird behavior like the one you are describing. Please try disconnecting the actual motor and see if the problem still occurs. If not, you would need to modify your board schematic to stabilize the power.
Hi,
You can do this by editing the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\QuickSetup\interfaces.xml file.
Hi,
Please double-check that you have the access to the specified file and that it’s not open in any other program (sometimes refreshing the cache while Clang IntelliSense is still scanning the source gets this error). If nothing helps, please try closing Visual Studio and deleting the file (or the entire 0002 folder) manually.
Hi,
This is by design unless you built OpenCV from sources yourself (or manually downloaded/installed debug symbols if your distro ships them). We would recommend building OpenCV from scratch (e.g. by following this tutorial). The new CMake Project Subsystem in VisualGDB 5.3 should make it much simpler as well.
Hi,
Yes, the problem occurred because our register parsing was confusing offsets and absolute addresses. We have fixed that.
The window bug should be fixed in v5.3 Preview 2 (or you can simply restart VS and run the update again).
Hi,
Thanks for reporting this, looks like our bug. We have fixed it and released an update to the Tiva package.
Please update via Tools->Manage VisualGDB Packages.
Hi,
The Clang engine is designed to only work with VisualGDB projects, so the easiest workaround would be to create a new project configuration that will be recognized as a VisualGDB-based configuration. Please try importing your project into another GNU Make-based project (not MSBuild-based) and check the VS project properties. The configuration type will be set to “Makefile” and the “NMake Output” will point to a .vgdbsettings file containing various project-specific settings. Please copy that file to your main project directory and create another Makefile configuration using the VS configuration manager. Ensure its output points to the .vgdbsettings file, the include directories are correct and the “forced include files” contain the gcc_<config>.h file with built-in macros dumped from gcc.
As long as these criteria are met, the Clang IntelliSense will recognize this configuration as a VisualGDB-based configuration and will handle the project as usual.
Hi,
The breakpoint issue could be caused by your code reassigning JTAG pins as regular GPIO (or otherwise tampering with the on-chip debug unit). Please try pinpointing the exact place in your program flow after which the breakpoints stop working.
The link error looks like it’s caused by switching the toolchain to a different version. Please try checking/unchecking the “reduce size of C++ binaries” checkbox on the first page of VisualGDB Project Properties. This should regenerate the necessary settings and fix the problem.
Hi,
With the new system there won’t be any path stored inside the .vxcproj file at all. Instead it will store the BSP ID and version and use the $(BSP_ROOT) syntax. When opening the project file with VisualGDB, it will automatically locate the BSP based on the ID and version and provide the $(BSP_ROOT) variable to Visual Studio so that VS can find the source files on your machine.
This could happen if some of your file paths contained spaces. Please double-check that the toolchain, project and the code generated by STM32Cube does not reside in paths with spaces (or switch to the MSBuild system that supports paths with spaces since VisualGDB 5.3).
Hi,
Please try rebuilding the project. The .bin file should be generated in the same directory as the regular ELF file (with no extension).
If nothing helps, please try enabling diagnostic MSBuild output via Tools->Options->Projects and Solutions -> Build and Run and check for the details on the “GenerateBinFile” target.
Hi,
Please double-check that you have X11 installed on Raspberry Pi. Does running other programs (like xterm) over SmarTTY work?
