Forum Replies Created
-
AuthorPosts
-
February 19, 2024 at 09:01 in reply to: What is the official/recommended method for installing the latest EPS toolchain #35357
support
KeymasterHi,
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.
support
KeymasterHi,
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/
support
KeymasterNo problem. We will monitor the feedback from other users and will consider adding a warning if others encounter the same issue.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
February 13, 2024 at 19:03 in reply to: Is there a tutorial how to use "Include What You Use (ICWYU)" ? #35331support
KeymasterHi,
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.
February 12, 2024 at 18:05 in reply to: Defining pre build command to build one file each time #35325support
KeymasterHi,
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.
February 10, 2024 at 13:14 in reply to: Defining pre build command to build one file each time #35323support
KeymasterHi,
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.
support
KeymasterHi,
Sorry, we do not have any plans for updating the RISC-V toolchain at this point. Feel free to build one manually from sources.
support
KeymasterHi,
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.
support
KeymasterHi,
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.
Attachments:
You must be logged in to view attached files.January 23, 2024 at 15:44 in reply to: Linker file changes to default when cube project is reloaded #35292support
KeymasterHi,
Thanks, we have reproduced and fixed the issue. Please try this build: VisualGDB-6.0.4.5100.msi
support
KeymasterHi,
Based on what we see, we do have traffic from Estonia, so it looks like some glitch on your side or with your ISP, sorry.
support
KeymasterSorry, it looks like a network issue on your side. Please contact your system administrator for help.
support
KeymasterHi,
This error means that something on your computer is preventing VisualGDB from accessing Internet and downloading the packages. Please double-check your firewall/proxy settings and make sure VisualGDB can connect.
-
AuthorPosts