Forum Replies Created
-
Posts
-
Hi,
The -Wno-dev could be added to CMake command line via VisualGDB Project Properties -> CMake Project -> CMake command.
That said, we have looked into it and replaced exec_program() with execute_process() as recommended by CMake. We initially used exec_program() because of a CMake bug with quoting, but we ran some additional tests and managed to find a workaround that works. Feel free to update to this build: VisualGDB-6.0.4.5135.msi
Hi,
The 20-line limit in tooltips is by design to prevent them from filling the entire screen if VisualGDB attributed too many comments to the function declaration. You can easily change it via Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Tooltip line limit.
The excessive empty lines were indeed due to a bug. We have fixed it in this build: VisualGDB-6.0.4.5135.msi. We also added a setting (Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Condense function summaries) that allows removing extra lines between function argument descriptions, “returns” part and other similar blocks (requires reopening the project).
The </param> and </summary> should work the same – VisualGDB would trim the empty line at the end, and re-insert it on a higher level (between different parameters and different high-level blocks like summary or returns). If you meant something else, feel free to provide more details and we will look into it.
Hi,
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Hi,
You can manually install the toolchains to different directories, select “import by locating gdb” and point VisualGDB to the toolchain.xml files instead of gdb.exe (ESP32 has a very special toolchain layout, so the usual detection logic indeed won’t work).
This has been fixed in VisualGDB 6.0 – the “import” link now mentions toolchain.xml explicitly.
Hi,
Last time we checked, it requires the same toolchain as v5.1, so you can simply install it into it via the ESP-IDF release selector.
We will eventually release another toolchain that includes it out-of-the-box, but since the current toolchain works just fine with one very straight-forward extra step, it’s not a very high priority.
Update: We have released an updated toolchain with ESP-DF 5.2 included. You can download it here: https://gnutoolchains.com/esp32/
No problem. We will monitor the feedback from other users and will consider adding a warning if others encounter the same issue.
Hi,
The heap view in Live Watch is indeed designed for much smaller heaps that would typically fit into the on-chip SRAM and can be polled at a reasonable rate. Reading out 16MB of SDRAM over a typical JTAG connection would indeed take several minutes, and would not be really practical.
Hi,
Sorry, it doesn’t look like any known issue. Most likely, some file somewhere got corrupt and is interfering with IntelliSense.
Our best advice would be to reset the environment (toolchain, ESP-IDF) and try creating a new project from scratch. If the problem doesn’t reappear on the new project, try comparing the project files between the working and non-working projects to pinpoint the setting that could be causing this.
Hi,
This is really something to check with the ICWYU developers. If they are willing to make it compatible, we can provide a public interface for their extension to query the VisualGDB project structure (it’s actually rather straight-forward on our side – just a list of files and corresponding Clang flags) and help them get it working. If not, it’s really not up to us, sorry.
Hi,
You can configure custom pre-build steps via VisualGDB Project Properties -> Custom Build Steps.
As for the command line, it’s something for you to figure out. VisualGDB can run arbitrary command lines at different times during the build as configured via VisualGDB Project Properties, but it’s up to the user to make sure these command lines make sense and work as expected.
Hi,
There isn’t any specific setting that would do that directly, but you could try adding a pre-build step that would regenerate some header file, and including that file from all sources that you would like to be rebuilt.
Hi,
Sorry, we do not have any plans for updating the RISC-V toolchain at this point. Feel free to build one manually from sources.
Hi,
Sorry for the delay. We have updated our STM32MP1 toolchain to the latest openstlinux-6.1-yocto-mickledore-mp1-v23.11.15 release.
We have not explicitly tested it on STM32MP13, however we did compare the Linux-based toolchains produced by the ST build scripts for stm32mp1 vs stm32mp13-disco targets and they looked pretty identical (sysroots/device trees are different though).
You should be able to target STM32MP1 devices with the new toolchain, as long as you replace its sysroot with the one from your current Linux-based toolchain (cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi subdirectory). You can also try using the original sysroot: as long as you are not building any kernel modules with it (that is not possible anyway), there’s a high chance it will work just fine.
Hi,
It should work just fine, as long as the debug session is running, Live Watch is enabled, and VisualGDB understands the context of the variable (top right corner of the navigation bar).
If not, feel free to share a screenshot demonstrating the problem, and we’ll look into it.
That said, you can also switch Live Watch to globals view and enable the “Current file only” mode to quickly see all variables in the current file, and flag the important ones as favourites.
