Forum Replies Created
-
Posts
-
Hi,
Yes, we removed the compactcpp library from the latest toolchain as it is no longer needed with the latest libc++ optimizations. VisualGDB would normally update your project automatically if you change any settings on the first page of VisualGDB Project Properties, but removing it manually should produce exactly the same result and is totally OK.
Hi,
Please try selecting “Show STM32CubeMX samples” on the sample selection page in the VisualGDB wizard. It will show the sample projects that came with the STM32CubeMX software libraries and might include an out-of-the-box UART example for your board.
Hi,
Sorry, we don’t have any tutorial for the STM32Cube programming tool. However you can easily program your firmware without starting a debug session by selecting Debug->Program Embedded Firmware.
H,
Thanks for the repro. It looks like your toolchain fine sets the CXX executable in a way that confuses CMake. Please try moving the compiler arguments into a separate CMAKE_CXX_FLAGS statement:
set(ENV{CXX} "arm-vgdbtest-linux-gnueabi-g++" CACHE STRING "" FORCE) set(CMAKE_CXX_FLAGS "-march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 --sysroot=$ENV{SDKTARGETSYSROOT}" CACHE STRING "" FORCE)Hi,
Thanks for reporting this, looks like a side effect of the recent WPF redesign of the authentication GUI. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2081.msi
Hi,
OK, we have released v5.4 Preview 1 that supports the new advanced ESP-IDF project subsystem. You can download the build here. You can read the announcement with the main highlights of the new subsystem here: https://sysprogs.com/w/announcing-visualgdb-5-4-preview-1/.
Hi,
Perhaps you have configured the VisualGDB’s raw terminal to open COM2? Either way, please try searching the .vgdbsettings file for any mentions of COM2. If none are found, please attach a screenshot of the error message you get and we will try to suggest you which setting could be affecting it.
Hi,
Thanks, we have rechecked the updated example. VisualGDB currently only supports one test binary per project (we might be able to improve it in v5.4), sorry. As a workaround please try defining tests in static libraries and linking them into one large executable.
We also tried actually running tests in your project, however they did not report the results as the SysprogsTestHook_TestStartingEx() function was never called. This could be caused by differences between the test framework you are using and the one VisualGDB puts into newly created projects. Please try creating a regular MSBuild-based test project, setting a breakpoint in SysprogsTestHook_TestStartingEx(), reviewing the call stack and analyzing why it doesn’t get called in your project.
Naturally once we officially support advanced CMake-based unit tests, we will ensure it works out-of-the-box.
Hi,
Yes, v5.3 won’t handle this correctly unless you edit the file. It will be fully fixed in the upcoming v5.4.
Hi,
Strange, we have just double-checked that project on a different machine and it still worked. Please double-check the timestamp on the C:\Program Files (x86)\Sysprogs\VisualGDB\CppEngineCore64.dll file – it should be February 26th. If not, please double-check the VisualGDB version under Help->About VisualGDB and try reinstalling the temporary build we mentioned.
Hi,
Any edit to the source file should be sufficient to rebuild the related parts of the cache. If this still doesn’t work, please let us know.
Hi,
Unfortunately the way WSL allocates memory is completely outside VisualGDB’s control. Please try running the same project on a 64-bit Kubuntu VM, if the problem is caused by WSL-specific patches, it should help resolve it.
Hi,
Thanks, we have reproduced and fixed the problem. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2077.msi
