[support]

Hi,

We have just retested it with the ESP32-S3-BOX and it worked just fine. Please make sure you actually install the WinUSB driver for the “USB Composite device”  as VisualGDB suggests (you need to select “USB Devices” in the “Debug Using” field for VisualGDB to check the drivers).

The default driver layout (separate serial port & debug nodes) appears to be incompatible with the current version of OpenOCD.

[support]

This looks like an error coming from the ESP-IDF build system and not something specific to VisualGDB. Please refer to the ESP-IDF documentation for more details on it.

If you can build the same project outside VisualGDB, but not with VisualGDB, please follow the troubleshooting instructions here to get it working.

[support]

Hi,

Most likely, some build parameters (e.g. optimizations, libraries, etc.) are different. Since both VisualGDB and STM32CubeIDE use the same compiler (gcc), you can get them to produce nearly identical output (the only difference will be the order of symbols in the image), however it will require comparing build command lines side-by-side. We have a detailed tutorial showing how to do it for another compiler here.

Another option would be to use the Embedded Memory Explorer to quickly compare the footprints of 2 builds to see if there is any obvious difference (e.g. some symbols only present in one file, or every symbol being proportionally larger, implying different optimization).

[support]

Sorry, VisualGDB 5.3 is 5 years old, is no longer maintained and does not support the new package list format. Please consider updating to the latest VisualGDB 5.6.

[support]

Unfortunately, it is hard to suggest anything specific based on the description you provided.
In order for us to provide any help with this, we need to be able to reproduce the problem on our side.
Please provide complete and detailed steps to reproduce the issue as described below:

1. The steps should begin with launching Visual Studio. They should include every step necessary to create the project from scratch and reproduce the issue.
2. Please make sure the steps do not involve any 3rd-party code as we will not be able to review it. If the problem only happens with a specific project, please make sure you can reproduce it on a clean project created from scratch.
3. The steps should include uncropped screenshots of all wizard pages, VisualGDB Project Properties pages and any other GUI involved in reproducing the problem. This is critical for us to be able to reproduce the problem on our side.

You can read more about the best way to report VisualGDB issues in our problem reporting guidelines, If you do not wish to document the repro steps and save the screenshots, please consider recording a screen video instead and sending us a link to it.

Please note that many VisualGDB issues are caused by selecting an incompatible combination of settings at some point. We are generally not able to review specific projects and find the specific settings that were set incorrectly. We recommend checking the projects into source control and keeping a track of all changed settings to avoid breaking the projects.

You can also try checking various diagnostic output from various parts of VisualGDB as described on this page. Although we won’t be able to review it for a specific project unless the we can reproduce the problem from scratch, checking it might provide some clues on what is causing the unexpected behavior.

[support]

Hi,

No problem, please let us know the email address associated with your license key, so that we could check your support status, and we will be happy to help you.

[support]

Hi,

This looks like an issue in OpenOCD rather than something VisualGDB-specific. You can try building OpenOCD from sources by following this tutorial, and then step through it to understand what is going on.

Another option would be to switch to Segger J-Link. It comes with its own fully supported replacement to OpenOCD, that generally works better for many devices.

If the Atmel IDE works well, you can also try using Process Monitor to to see if uses gdb and whether it launches its own gdb stub similar to OpenOCD. If both are true, and you can run the same stub manually (and connect GDB to it), you can configure VisualGDB to launch it as well by selecting the “Custom GDB stub” mode in VisualGDB Project Properties -> Debug Settings. Note that the last option is something to do at your own risk, as it involves running undocumented Atmel tools.

[support]

Hi,

This is actually shown right after the instructions to dump the command line in the same troubleshooting page. You will likely need to set it for both CMake and Make/Ninja commands.

That said, it looks like your manual setup is using a different toolchain (esp-2022r1-RC1-11.2.0), that would explain the different behavior.

The best way to integrate it would be to:

1. Create a backup of the c:\SysGCC directory
2. Delete the old ESP32 compiler directory (E:\sysgcc\esp32\tools\xtensa-esp32-elf\esp-2021r2-patch3) and copy the 2022r1 version under E:\sysgcc\esp32\tools\xtensa-esp32-elf.
3. Edit toolchain.xml and bsp.xml, replacing xtensa-esp32-elf/esp-2021r2-patch3 with xtensa-esp32-elf/esp-2022r1-RC1-11.2.0 where appropriate (please use extra caution, since ESP32-S2/C3 targets use separate toolchains in their own directories).
4. Reopen the solution.

Again, this is something to do at your own risk. We will do all these steps, retest everything and publish a ready-to-use package once Espressif deems them stable enough for a general release. We intentionally do not do this for pre-release versions, as they tend to be much less reliable and often change in various subtle ways before the final release.

 

[support]

Thanks, we have rechecked that Atmel SAM BSP, and confirmed that the default sample was using the incorrect syntax (that was initially derived from the SAM0 sample).

We have fixed the issue here and released an updated BSP resolving it. You can update to it via VisualGDB Package Manager.

[support]

Sure, you can always follow the troubleshooting instructions from the same documentation page you mentioned. They show how to narrow the problem down to specific command lines, so you can compare and adjust them outside VisualGDB.

[support]

Hi,

We usually test VisualGDB with the new ESP-IDF versions once they are officially released by Espressif (i.e. mentioned as a stable release on the releases page and distributed via the Espressif’s installer). It typically takes a couple of weeks after the official release from Espressif for us to retest everything and update VisualGDB.

If the release is not mentioned there, it has likely not been fully tested by Espressif yet, may not be usable yet, and may change considerably before the final release. If you would like to get a timeframe of the official ESP-IDF v5 release, please contact Espressif.

[support]

Hi,

The support for a specific language standard (e.g. C++20) comes from the gcc version included in your toolchain. VisualGDB works just fine with it, as long as your toolchain supports it.

The wizard indeed shows language standards up to C++17, but you can always change the standard to C++20 via project properties, once you have selected a toolchain compatible with it.

For CMake projects, you can also just set the language standard directly by editing the CMakeLists.txt file. VisualGDB will automatically pick it up once you reload the project.

[support]

Hi,

You can try contacting Espressif for help, or patching the ESP-IDF build scripts yourself. VisualGDB works on top of the existing scripts and cannot do it for you.

The “program from file” option programs the specified file into the bounds of the partition reported by ESP-IDF. This is done once and does not change the ESP-IDF project properties, or override the regular ESP-IDF programming logic.

[support]

Hi,

No problem, this looks like a known issue that is already fixed in our development branch. Please try this build: VisualGDB-5.6.106.4630.msi

We are maintaining our NRFConnect support. We periodically check compatibility with the latest SDK versions, update VisualGDB accordingly and are happy to offer numerous productivity features that make VisualGDB development experience better compared to VSCode.

[support]

Hi,

The exact FLASH command line is not directly under VisualGDB’s control, however we can explain what parts are involved in computing it so that you can pinpoint the correct setting:

1. ESP-IDF enumerates all KConfig files referenced by the project and stores them in the project_description.json file.
2. VisualGDB scans the KConfig files referenced there and shows the ESP-IDF-specific settings based on them.
3. When you change those settings in the GUI, VisualGDB updates the sdkconfig file.
4. When you build the project using ESP-IDF scripts, they pick up the settings from sdkconfig, and compute various command lines based on them.
5. Some command lines are saved to intermediate files such as flash_args

Modifying flash_args manually will indeed not work, since the build scripts will overwrite it. Instead you would need to find the ESP-IDF setting that controls its content and change it (either by editing sdkconfig directly, or via VisualGDB Project Properties that will let VisualGDB edit it for you). Searching ESP-IDF build scripts for flash_args or parts of the command line shown there could be a good starting point.

[Author]

Posts