[support]

Hi,

We have just rechecked it with a basic STM32F746NG project using the latest toolchain, latest GDB and the latest OpenOCD, and it worked just fine.

Most likely, something about your project is triggering a bug in some of the tools. Please try narrowing it down as follows:

1. Double-check that switching to the old toolchain, but keeping the latest OpenOCD fixes the problem. You can also check if using the previous OpenOCD with the new toolchain works (normally, the toolchain should not affect the FLASH programming at all). Make sure you fully rebuild the project after switching the toolchain.
2. If the problem is specific to the toolchain and is not affected by OpenOCD, try copying the old gdb executable into the new toolchain. Does the problem still trigger?
3. If the problem happens with the new toolchain and old GDB, it can be triggered by some optimization done by GCC. You can try comparing the 2 builds of the project with Embedded Memory Explorer. Is there something particular about the broken version (e.g. some section alignment is off, or some new sections have appeared)?

[support]

Hi,

The screenshot shows the include directories provided by the toolchain. The number there refers to the GCC version and not the language standard. If you need a newer gcc, you would need to check if your platform vendor provides one.

The language standard version (e.g. C++11 or C++23) can be configured via VS project settings (not VisualGDB Project Properties) -> C/C++-> Advanced -> Language Standard.

[support]

Hi,

The easiest way would be to manually patch the .vcxproj file, conditionally adding/Zc:__cplusplus when the DesignTimeBuild variable is set. This should affect IntelliSense, but not the actual build.

Another option would be to checking the _MSC_VER macro in some common header file, and redefining __cplusplus if it is set.

[support]

Hi,

Sorry, this is the side effect of how per-target building is handled. VisualGDB shows relevant CMake targets in Solution Explorer and allows building them via context menu. Generation of binary/hex files is done via separate CMake targets, so when you request CMake to build the actual executable target, it won’t build those.

If you have a complex scenario where another target requires these files, you can add an explicit dependency from that target to the binary file-building targets, so CMake will build them whenever it builds the target using them.

[support]

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.

[support]

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.

[support]

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.

[support]

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:

1. Does the key combination work for the newly created project?
2. If yes, does it work for other symbols in the main project?
3. If yes, is there something particular about the symbols that cannot be renamed (e.g. defined in .h files, but not .c files)?

[support]

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/

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

Hi,

This looks like something is broken in the environment or CMake files. The supported way to troubleshoot such issues would be to:

1. Reproduce the issue in VisualGDB and export the ESP-IDF command line it uses to a batch file (see this page).
2. Run the batch file separately and ensure the problem persists.
3. 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.

[support]

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.

[Author]

Posts