Forum Replies Created
-
Posts
-
Hi,
No problem, we can try to help you. Please let us know the email address associated with your license, so that we could link it to your support profile.
Hi,
The VisualGDB setting for removing the debug info would be Linker->Advanced->Strip Debug Information. It enables the “-Wl,–strip-debug” option mentioned by @bflannery.
But you can also add a post-build step for stripping it, moving it to a separate symbol file as shown here.
Hi,
Our BSPs are directly derived from the device SDKs provided by the device vendors (ST in this case). You can find out the exact SDK versions used to build each BSP in the SDKVersions.xml file (STM32 only) and then check the SDK changelog on the ST website.
Hi,
We have just rechecked the rename command using Clang IntelliSense and it worked just fine; hence, the issue is likely used by something else.
In order to narrow it down, please try creating a new project from scratch, right-clicking in the middle of the “main” word of the main() function and selecting “Rename”. Does it work? If yes, please try checking:
- Does the key combination work for the newly created project?
- If yes, does it work for other symbols in the main project?
- If yes, is there something particular about the symbols that cannot be renamed (e.g. defined in .h files, but not .c files)?
Hi,
No worries, we have released an updated toolchain package. You can now install it via VisualGDB Package Manager, or get it directly from here: https://gnutoolchains.com/esp32/
Hi,
VisualGDB Properties are merely a GUI for editing various ESP-IDF statements. Please refer to the ESP-IDF documentation to see if there is a statement that would cover your use case.
If you can point out a specific statement (i.e. would know how exactly to edit the CMake files to get the desired result), we can advise you on the GUI setting that would do it for you.
Hi,
This is by design. Moving files outside Visual Studio does not automatically update the Visual Studio project file and the refresh/reload command does not do it either. You would need to re-add the files, or edit the .vcxproj file manually.
This is the normal behavior of Visual Studio and is not specific to VisualGDB.
Hi,
Sorry, this dialog is a part of the GNU Make project subsystem that is deprecated and not recommended for new projects. Please consider using Advanced CMake instead, or just referencing the package manually.
Hi,
Thanks for confirming your license. We have rechecked the SVD files published by Espressif and they now look better than what we managed to parse from the header files in ESP-IDF.
We will use them instead of the old files for the next toolchain releases.
You can patch any older toolchain by downloading this file [peripherals.7z], and extracting it to <toolchain directory>\esp32-bsp, replacing the existing files in the peripherals folder.
Hi,
This looks like something is broken in the environment or CMake files. The supported way to troubleshoot such issues would be to:
- Reproduce the issue in VisualGDB and export the ESP-IDF command line it uses to a batch file (see this page).
- Run the batch file separately and ensure the problem persists.
- Refer to the ESP-IDF documentation to solve the problem outside VisualGDB (e.g. add missing environment variables, or fix broken files).
If it turns out that a particular change to the batch file (e.g. adding an environment variable) fixes the problem, let us know more details and we will help you configure VisualGDB to adjust its command line, matching the fixed batch file.
Hi,
This could be related to an issue we previously noticed with the ARM toolchain. Older versions of it appeared to come with unoptimized builds of GDB, so they were very slow at loading the symbols. Our toolchain is a repackaged version of the ARM toolchain, so it would be affected by this as well.
We have just updated it using a clean optimized rebuild of the latest GDB 15.1. Feel free to update it via VisualGDB Package Manager.
Hi,
This is likely some race condition between loading the colors from VS settings and using the loaded colors to render the memory window contents. However, it is hard to say anything specific without the logs from the new build. The log from 6.0R3 doesn’t help because v6.0R3 does not have the logic for logging the memory window theme events.
You can try this build: VisualGDB-6.0.103.5202.msi. If it still produces strange errors, it could be an indication of something else going wrong (e.g. some common assemblies or cache being corrupt). You can try creating a new project from scratch and trying out the memory window with it. If it still fails with strange errors, please share more details (project type, exact steps to create it, uncropped screenshots of the VS window showing the error).
OK, thanks very much for pointing this out. It turns out, when we moved the regex to the XML file and extended it to handle the (WSL (…)) syntax, it ended up with a typo, that still passed the test cases by coincidence.
We have updated the regex to
\(WSL(| \(.*\))\), covering both short and extended form.Feel free to update to this build: VisualGDB-6.0.103.5202.msi
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 and install the latest VisualGDB 6.0R3 that includes the latest fixes and optimizations.
Hi,
The second IntelliSense popup looks like it’s coming from another VS extension. Most likely, it does not recognize VisualGDB, and tries to show its popup nonetheless. You can try disabling other VS extensions to see which one it is.
Another option would be to change the mechanism used by VisualGDB to display the suggestion popups (Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Smart Suggestion List GUI). Some of the options there could interfere less with the other extension.
