Forum Replies Created
-
AuthorPosts
-
support
KeymasterGood to know it works.
Regarding the Arduino IDE, it looks like some sort of a conflict between different versions of the packages in the Arduino directory and the VisualGDB directory. We should be able to fix this if you could archive the entire Arduino IDE directory and also the C:\Users\Johanan\AppData\Local/Arduino15 directory so that we could reproduce everything on our side. But since the current workaround fixes the problem, you can simply proceed with having the Arduino IDE directory unspecified.
October 9, 2019 at 22:27 in reply to: CMake project not recognizing header files in sysroot/usr/local/include #26128support
KeymasterThanks, this indeed helps understand what is going on.
Indeed, the
../../=/usr/local/include
syntax is incorrect (the correct one should be${CMAKE_SYSROOT}/usr/local/include
). The development branch of VisualGDB 5.5 should already use the correct syntax, but if you don’t want to upgrade before v5.5 reaches the stable release stage, simply try replacingC:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot
with${CMAKE_SYSROOT}
and the project should build both on Linux and Windows.October 9, 2019 at 15:49 in reply to: Wrong codepage used in dialogues (system instead of UTF8) #26126support
KeymasterSorry, this looks like something inconsistent between the system codepage, git codepage and MinGW codepage. Given that the problem does not affect build and that non-latin characters in paths are not recommended due to conflicts with other tools (e.g. gdb), we will not be investigating this further, sorry.
support
KeymasterThis looks like some sort of incompatibility between a specific version of the toolchain and a specific version of OpenCV.
Unfortunately, as both components are outside of our control, we are not able to cover this with our regular technical support, so our best advice would be to try asking on the OpenCV forums if anyone has encountered similar errors before.
October 9, 2019 at 00:24 in reply to: CMake project not recognizing header files in sysroot/usr/local/include #26117support
KeymasterSorry, it’s hard to suggest anything specific without knowing more details (how exactly is the target declared, what is the current directory with the header file and exactly is is spelled in the Makefile, what exactly gets edited in the CMakeLists.txt file).
One possible cause for this would be CMakeLists.txt using the regular /path/on/target syntax to specify include directories instead of ${CMAKE_SYSROOT}/path/on/target. The former syntax will only work when compiling directly, while the latter will work both when building on Linux and Windows.
VS properties for the target can be opened by right-clicking on the target (specific executable or library) in Solution Explorer and selecting “Properties”.
Edit: the VisualGDB 5.5 development branch does automatically use the ${CMAKE_SYSROOT} syntax for automatically discovered directories (e.g. VisualGDB-5.5.1.3300.msi), however it hasn’t fully passed all our internal tests and may be less reliable than the stable v5.4 release.
-
This reply was modified 5 years, 11 months ago by
support.
October 8, 2019 at 21:27 in reply to: Embedded Memory explorer uncorrect memory name visualization #26114support
KeymasterThanks, looks like this memory layout slightly changed the format of the output from objdump that was used by VisualGDB to gather disassembly data.
We have fixed it in the following build: VisualGDB-5.5.1.3299.msi
support
KeymasterSorry, this might be something set on the VS level. Please try running notepad.exe instead of the batch file (so that the build waits until you close Notepad).
Then use the Process Explorer to check the environment block of the Visual Studio itself (devenv.exe), launched Notepad instance and the MSBuild executables (msbuild.exe) if you are using MSBuild.
Let us know at which stage is the PATH reset and we might be able to suggest a workaround.
support
KeymasterThanks, it looks like the new STM32 Arduino package builds executables without debug information by default.
We have updated VisualGDB to automatically detect and fix this condition: VisualGDB-5.5.1.3298.msi (see the bar on top of the source files belonging to the Arduino project).
support
KeymasterHi,
Sorry, no news for STM8. STM32WB is already supported (see the following tutorials: https://visualgdb.com/w/tutorials/tag/stm32wb/).
October 8, 2019 at 19:58 in reply to: CMSIS-DAP device showing up multiple times and debug fails #26107support
KeymasterNo problem, it turned out our OpenOCD toolchain was using the old-style definition file that had hardcoded paths. We have updated both the toolchain and the OpenOCD repository so that they don’t have any paths hardcoded and will work out-of-the-box with arbitrary locations.
We have also fixed the “Debugging exited without any breakpoint hits” error (there was a glitch in one of the CMakeLists files, although it’s hard to say why it didn’t trigger with the old path/toolchain).
Let us know if you find the root cause of the serial number matching problem and we will be happy to update our OpenOCD package.
support
KeymasterSorry, we have tried reproducing this for the latest supported ESP-IDF version (4.0), but could not get the behavior shown in the video.
If you could confirm that the problem persists with ESP-IDF 4.0, please share the full repro steps from creating a project. If the problem is specific to ESP-IDF 4.1, please consider editing the configuration manually until ESP-IDF 4.1 reaches the “stable release” stage and is officially supported by VisualGDB.
support
KeymasterSorry, we are not aware of this issue. Please try checking if other variables get overridden as well (e.g. by running ‘set’ instead).
If this doesn’t help, please try creating the most basic repro project and share it with us so that we could try replicating this. That said, please also ensure the VS instance you are using doesn’t inherit some custom environment and that your environment block doesn’t exceed Windows limits.
support
KeymasterHi,
No problem, we have rechecked the latest EFM32 SDK (5.8.3) and updated the VisualGDB’s EFM32 BSP to match it.
Please update it via Tools->Manage VisualGDB Packages and you should be able to use the new devices.
support
KeymasterNo problem, please try this build: VisualGDB-5.5.1.3294.msi
We have added a context menu command “Set as Main Component” to the ESP-IDF component items in Solution Explorer for CMake projects. Flagging an arbitrary component as the “main” one will now merge its contents directly under the top-level item in Solution Explorer.
support
KeymasterHi,
Real-time variables are included in the Custom edition of VisualGDB and higher. If you are using a lower edition, you can upgrade it here: http://visualgdb.com/buy/
If you are using VisualGDB Custom, please share a screenshot of the Help->About VisualGDB window and a screenshot of the Visual Studio window with the Debug->Windows menu open and the VisualGDB-based items missing and we will help you get them to appear.
-
This reply was modified 5 years, 11 months ago by
-
AuthorPosts