[support]

Hi,

Yes, please use the “Custom Installation” button in the installer and it will ask you which versions of Visual Studio you want to support.

[support]

Hi,

Thanks for the log. It looks like you are using VisualGDB 5.3 that is not the latest available version. Please try VisualGDB 5.4 Preview 3 (or this build) and if the problem persists, submit an updated log.

[support]

H,

Yes, please reference the “Fast Semihosting” framework via VisualGDB Project Properties -> Embedded Frameworks.

[support]

Hi,

Just wanted to let you know that we did a few extra tests on our side and it looks like we were able to locate and fix the source of the problem. We will release an update to the ESP32 toolchain after the upcoming v5.4 Preview 4 release that will include the newest OpenOCD build with this issue resolved. Please expect an update within the next 3 business days.

[support]

Hi,

Sorry, unfortunately this error message is too generic to fully pinpoint the problem. If you could try clicking the “show details” button and paste the results here, we should be able to see what is going on and suggest a fix/workaround.

[support]

Hi,

Sorry, OpenOCD is maintained by Espressif, please consider asking at their forums. Our changes to their OpenOCD fork focus on usability improvements and out-of-the-box experience on Windows, but we don’t touch low-level device interaction logic as it changes very often between releases and relies on undocumented ESP32 internals.

We will run a few advanced tests on this build before releasing it officially and might be able to fix it if we reproduce it reliably and it turns out to be something trivial, or delay until Espressif fixes it, but we are not able to do any deep diagnostics beyond that.

Another option would be to try finding out the exact commit hash of the Linux build you are using, merging that commit into our OpenOCD fork and building it. If the problems you are experiencing are caused by some changes after that commit, this might help.

[support]

Hi,

Strange. The version number on our server is 1694. Perhaps something on your side has cached the old binary? Either way, please try this URL:

http://sysprogs.com/files/tmp/esp32/ESPxxDebugPackage.dll

Please double-check the package version after downloading/installing it.

[support]

Hi,

Thanks for the log file. Looks like the “gdb stub” debug method was not handling the esp-idf 3.1 changes properly.

Please try this build of the debug package: http://sysprogs.com/files/tmp/ESPxxDebugPackage.dll

[support]

Hi,

No problem, we will be happy to clarify this here.

The Embedded Frameworks is a convenient shortcut for adding/removing groups of source files (and associated flags) to the project. E.g. if your project references the “FreeRTOS” framework, VisualGDB will automatically add the related sources, include directories and preprocessor macros to the project. Furthermore, if the exact settings change after a BSP update, you will be able to update your project by simply regenerating BSP-related files. The embedded frameworks have a varying degree of accuracy depending on the platform. For platforms that provide structured definition of components they are automatically derived from those definitions. For Nordic devices they are derived from scanning the source folders during our BSP build process and applying a set of simple rules.

The files added via Embedded Frameworks are placed under the “Device-Specific Files” folder in Solution Explorer. This folder is managed by VisualGDB and any changes you make under it (e.g. new files/removed files) will be overwritten next time you regenerate the BSP-specific files. This is by design as it allows updating the project when the list of the sources corresponding to a specific framework changes. All files added to other folders in Solution Explorer (and the “Excluded from Build” flag on the files originating from the frameworks) will be preserved.

Our example projects may indeed include many extra frameworks, as the internal structure of the SDK changed considerably and we have not optimized this yet. The good news is that the link-time garbage collection should take care of this, so the size of the final binary will not be affected.

Thanks for the suggestion with the app templates, we will investigate the possibility of wrapping them as VisualGDB project templates and will include them unless we discover some blocking issues.

[support]

Hi,

It looks like an incompatibility between the debug information format stored in the object files and valgrind. You might be able to resolve it by explicitly forcing the debug format to an older version of DWARF by adding “-gdwarf-2/3/4” to the CFLAGS/CXXFLAGS.

You can access advanced VisualGDB logs (that include all command lines launched via SSH) via View->Other Windows->VisualGDB Diagnostics Console.

You can add extra arguments to Valgrind via the “Additional Valgrind flags” field in the New Profiling Session window.

If you need any further help, do not hesitate to get back to us.

[support]

Hi,

The OpenOCD build that is included in our toolchains includes some fixes and usability improvements compared to the original ESP32 OpenOCD. You can get the source code (including a VisualGDB project for convenient building with CMake) here: https://github.com/sysprogs/openocd-esp32

For your convenience we have merged the latest commits from the Espressif’s branch into our fork and uploaded a built version here: http://sysprogs.com/files/tmp/esp32/openocd.exe

[support]

Hi,

This looks like VisualGDB is not able to extract the FLASH programming parameters from the esptool command line. We would need to see the BuildCommandLines.txt file from the VisualGDBCache directory in order to diagnose this further.

 

[support]

Hi,

Sorry about that, looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2365.msi

 

[support]

Hi,

Strange. This might come from some settings cached by the previous build. Could you please try creating a new “blink” project using the latest IDF from scratch? If this works, please try deleting the VisualGDBCache directory in the original project and then re-open it.

[support]

Hi,

Thanks you for purchasing VisualGDB. We have prepared a preview build including this fix: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2363.msi

If the ESP32 debug package fails to initialize, please replace the file <toolchain>\esp32-bsp\sysprogs\debug\core\ESPxxDebugPackage.dll with the following one: http://sysprogs.com/files/tmp/ESPxxDebugPackage.dll

 

[Author]

Posts