[support]

Hi,

Generally, it should work. However, for large projects, the profiler can sometimes have unintended side effects (e.g. causing stack to overflow due to requiring some extra stack space).

You can troubleshoot it as follows:

1. Try to instrument as little functions as possible. If it stops the problem from happening, some of the profiled functions might me manipulating the stack directly, or otherwise interfering with the profiler. You can narrow it down by instrumenting half of the functions at a time and seeing which half breaks.
2. Try checking the functions shown in the profiler window, or the variable values inside the profiler framework. Sometimes, it points to an obvious location that causes the problem (typically, a function manipulating the stack).

You can also try using the new Software Tracing introduced in VisualGDB 6.0. It is much less intrusive, can record the ARM cycle count each time the given line (or function) gets executed, so you can get precise timing on the function or even line level, and export it to Excel for a detailed analysis.

[support]

Hi,

VisualGDB uses the GNU Linker to link the built executables. You can pass additional flags to the linker via project properties (exact location depends on the project type). That said, we are not aware of any linker setting that would pad the ELF file up to the size of the MCU FLASH. You might be able to get it working with some tweaks to the linker script, but it’s not something that VisualGDB can do out-of-the-box.

[support]

For ESP-IDF and other CMake-based projects, the platforms/configurations are just a way to quickly pass different parameters to CMake. Normally, the configuration translates to the CMAKE_BUILD_TYPE value, and the platforms can be defined arbitrarily, with each platform having its own CMake flags.

This mechanism is completely separate from the regular MSBuild-based platforms and configurations. It is not designed for building ESP-IDF code for x86 and will not work even if you manage to somehow hardcode the x86 platform.

[support]

Hi,

The ESP32 projects work on top of the ESP-IDF build scripts. VisualGDB does not directly manage the build process for them, there are no MSBuild-style platforms and configurations (even file lists and settings are stored on ESP-IDF level), hence just adding an x86 platform it it won’t work.

Unless you are willing to port the ESP-IDF build scripts to support x86 builds, it would be way easier to create a separate project.

[support]

Hi,

Sorry about that, it’s actually a VisualGDB bug. It was handling the source, rsource and osource directives, but not orsource. We have fixed it in the following build: VisualGDB-6.0.4.5058.msi

[support]

Hi,

No problem, we will try to help.

VisualGDB used to follow this layout (stored relative paths for toolchains inside the project files), however most users would not want to check in the toolchains, and would instead have them installed manually, often in different paths.

So, we moved the logic for ensuring toolchain consistency to VisualGDB:

1. Each toolchain always has a unique ID/version combination (see toolchain.xml).
2. Each project always references a specific ID and version.
3. When you open a project, VisualGDB checks if the exact toolchain it references is installed, and uses the location when running all the tools without hardcoding it in the project file.
4. If the toolchain is not installed, but comes from us, VisualGDB suggests automatically installing it.

So, you have all the advantages of a checked in toolchain (solid versioning, each project referencing a specific version, having multiple versions installed at once) without having to overload the Git repository with rather bulky toolchains (yes, it could be a submodule).

So, to the points you mentioned:

1. You don’t actually need to coordinate toolchain updates. Assume, you wanted to switch the project from gcc 10 to gcc 12:
   1. You change the toolchain via VisualGDB GUI project files and check in the project files.
   2. Users who check out the new project version will get a prompt asking them to download the new toolchain. They could install it side-by-side with the old one (to a different directory).
   3. When they open the older version of the project, VisualGDB will automatically use the old toolchain. If they open the newer version again, VisualGDB will use the new one.
2. The toolchain version is transparently stored inside the project files. The only issue is that if you have multiple projects in the same repository, switching the toolchain would require updating all relevant project files, as opposed to just 1 git submodule reference.
3. Reviving old projects should be fine, as long as you keep the toolchain installers. If you are using our toolchains, you can download them from https://gnutoolchains.com/ and install them manually later.

So, in essence, it already works very similar to a git submodule managed by VisualGDB on a per-project basis.

We could try adding some sort of workaround for relative references, but it won’t work with the regular GUI and may cause conflicts between toolchains referenced by version and toolchains referenced by relative path. On the other hand, we could update the current toolchain system to address some of the issues you mentioned:

• We could allow adding custom toolchain repositories (e.g. SMB shares with toolchain installers), so you could backup the installers, point VisualGDB to the repository and have it install the necessary toolchains on-demand without depending on our servers.
• We could add indirect toolchain references. Where each project will reference a “toolchain version file”, that will contain the toolchain ID and version. If you would like to retarget multiple projects to a new toolchain, you would edit that single file (similar to updating a git submodule reference) and VisualGDB will recognize it and use the new toolchain for all projects using that file.

[support]

Hi,

Normally, it should work automatically, since both bootloader and the main application will end up calling InitializeFastSemihosting() that passes the semihosting buffer location to VisualGDB.

However, it only works if the memory location of the buffer is the same between the bootloader and the main application (achievable via linker scripts).

If the addresses are different, please try this build: VisualGDB-6.0.4.5057.msi

[support]

We have just rechecked the settings testing GUI. OpenOCD indeed shows the “Error on socket” message (because VisualGDB closes the socket abruptly after confirming that it works) , but VisualGDB still shows the correct “Connection test succeeded” message. If you actually get an error message box instead, please feel free to attach a screenshot and we will investigate.

As for idf.py erase-flash, it is really something to check with Espressif. The idf.py file and all logic inside it comes from them. We don’t touch it, we don’t run any comprehensive tests on it beyond checking for unsatisfied dependencies, and rely on Espressif to fix issues in it.

You can try installing ESP-IDF 5.2 into the IDF 5.1 toolchain via the first page of VisualGDB Project Properties. Based on some quick tests, it is compatible with that toolchain, and might include some additional fixes.

[support]

Hi,

Sorry about that. This comes from the workaround used by VisualGDB to automatically resize List View columns. It tries to dynamically recompute the width of the Expression column based on the others, and it sometimes collides with the native WPF logic for resizing the columns.

Please try the latest VisualGDB 6.0 Beta 3. It defers the auto-resizing until you release the mouse button, so it should not interfere with the normal resizing and have this effect.

[support]

Please make sure you have a solid understanding of the following topics:

• How include search paths work, and how they are different from adding header files to Solution Explorer. We have a tutorial on this here, but you can find plenty of information from other sources as well.
• How C linking works, what are object files, libraries, library search directories and how symbol definitions are different from declarations in header files. We have another tutorial on this here.

These are fundamental C topics, and most VisualGDB features are designed assuming that the user is familiar with them. Trying to edit various files and using features like Header Discovery without understanding these will only cause cascades of increasingly strange errors.

Specifically to your questions:

1. This is the correct approach.
2. You can try using the “Add->Import folder recursively” command in the context menu or shared items projects.
3. Adding the top-level folder to the include search directories should not automatically add subdirectories.

[support]

Hi,

Sure, VisualGDB provides a special mechanism for fine-tuning that behavior:

1. It defines a __SYSPROGS_CODESENSE__ macro on the IntelliSense level. The macro is not defined during build, so all code enclosed in #ifdef __SYSPROGS_CODESENSE__ will only affect IntelliSense.
2. It forcibly includes %VISUALGDB_DIR%\gcc_compat.h file when using IntelliSense. The file contains various empty definitions for various macros that would otherwise cause errors.

You can eliminate the errors you mentioned by adding the following lines in gcc_compat.h (inside #ifdef __IAR_SYSTEMS_ICC__):

#define __no_init
#define __root

It will only affect IntelliSense and will not interfere with the build.

 

[support]

Hi,

This is to be expected. Different ESP-IDF versions are not 100% backwards-compatible, so the project may need some adjustment. If deleting the temporary subdirectories (build and .visualgdb) doesn’t resolve the problem, the project probably uses some settings that changed between the ESP-IDF releases.

VisualGDB cannot perform this kind of troubleshooting fully automatically. All it does in this case is notices that some header files referenced by sources are not present anywhere in the search path, and tries to automatically locate them and suggest the missing directories. This feature was designed to simplify importing of external projects (see this tutorial) and we do not recommend using it in this case. ESP-IDF projects specify many settings on a higher level, and overriding the include paths manually can create more problems than it would solve.

A good way of solving it would be creating a new project from scratch, checking where the missing include files are usually located and how are these components referenced, and then porting these settings to the broken project. You will likely find that some component names have changed, or some CMake-level statements use slightly different syntax.

[support]

Hi,

It really looks like something between the Espressif’s OpenOCD port and the chip. We are not affiliated with Espressif and do not have insights into their chips or tools beyond their official documentation.

If you suspect VisualGDB is using OpenOCD incorrectly, you can always try running the binaries from Espressif manually. If they also don’t work, please contact Espressif for further help. If they do work, please try comparing the command lines between the working and broken setup. If you can point out a specific difference causing the issue, we can gladly investigate it further.

That said, we have recently updated our OpenOCD package to match the latest release from Espressif. Please try installing it via VisualGDB Package Manager. It may contain a fix for this specific issue.

[support]

Hi,

OK, we’ve done some more investigation. It turns out the CoPilot extension pulls a dependency on the System.Windows.Interop.RenderingMode type, that somehow causes errors when trying to load XAML controls that have any non-dependency property called “Mode”.

There were a couple of more instances of these controls in VisualGDB code base, although they only affected a handful of settings pages.

We have fully resolved the issue to the following build: VisualGDB-6.0.4.5041.msi​. We renamed all conflicting properties and added an internal check for such conflicts to our build process.

[support]

Hi,

This indeed looks like a bug of the pic32 compiler. Please try running gcc manually using the command line shown in the error message. If it still fails, please consider reporting it to Microchip.

[Author]

Posts