[support]

Hi,

Thanks for pointing this out, looks like our bug. We have updated the installer to include the correct versions of the DLLs. Please try downloading/installing it again.

[support]

Hi,

Most likely some of the library directories/names settings are incorrect. Please try enabling verbose linker mode via VS project properties (not VisualGDB Project Properties) and check the build output. The linker will dump the full list of paths it checks when trying to locate the libraries.

[support]

Hi,

It looks like you have accidentally installed VisualGDB 5.3 again. Please double-check the installer you downloaded.

[support]

Hi,

We are indeed working on fully supporting CMake-based ESP-IDF projects, however this support is not 100% feature-complete yet. Please feel free to try the following VisualGDB and toolchain builds:

• http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2446.msi
• http://sysprogs.com/files/gnutoolchains/esp32/esp32-gcc5.2.0-r13.exe

Simply select CMake in the ESP-IDF project wizard (ensure you are using the new toolchain) and VisualGDB will create a CMake-based ESP-IDF project. You should be able to build it, debug it and use IntelliSense out-of-the-box, however the Solution Explorer will show the raw CMake targets (that are somewhat confusing with ESP-IDF) rather than meaningful app/bootloader/components and also adding new sources or changing target properties would result in potentially breaking edits of ESP-IDF build scripts (VisualGDB is not yet aware of the ESP-IDF-specific semantics for controlling target properties and will instead use the generic CMake semantics).

Feel free to try the builds above and feel free to post any feedback here.

[support]

Just wanted to share an update that we have created a repackaged version of the MSYS2-based toolchain that is 100% compatible with VisualGDB and is faster than our Cygwin-based toolchain. You can download the new toolchain release here: http://sysprogs.com/files/gnutoolchains/esp32/esp32-gcc5.2.0-r13.exe

Please use the following VisualGDB build: http://sysprogs.com/files/tmp/VisualGDB-5.4.5.2446.msi (note that it contains incomplete CMake support for ESP-IDF that is even faster than the regular Make-based build, but is not 100% feature-complete yet).

[support]

Hi,

It looks like an incompatibility between a particular Python module and the MinGW32 environment used by the Espressif’s toolchain. You could try using our Cygwin-based toolchain that is slower than the original MSYS2-based one, but should have less compatibility problems between various components.

It could be also worthwhile to report this to Espressif, as it looks like a bug that would trigger for everyone trying to use the new ESP-IDF with their own toolchain.

[support]

Hi,

Sorry, the BSP structure for SamD devices comes directly from the Atmel’s SDK package and it is indeed one of the least straight-forward ones. We would advise trying to find a sample project from Atmel that matches your hardware the best and then ensuring you reference the equivalent libraries on the VisualGDB side.

[support]

Hi,

Sorry, this issue happens because Visual Assist does not recognize Clang IntelliSense-powered projects as compatible projects and hence doesn’t work with them. The only way to resolve it would be to get the Visual Assist vendor to update their code to recognize VisualGDB projects. We are willing to provide any necessary assistance from our side to get this to work, however it would still require a change on their side.

[support]

Hi,

Thanks for clarifying this. If set can-use-hw-watchpoints affects the behavior, it is indeed caused by the target limitations (e.g. the kernel might not be allowing the user-mode code to access debug registers required for hardware watchpoints). We would advise trying to run gdb on the target manually with a test program. If the hardware breakpoints work there, the problem might instead be caused by an incompatibility between gdb an gdbserver, and trying a different combination of those components might solve it.

[support]

Hi,

Unfortunately it’s a bit more complicated. VS2017 uses private registry files that need to be programmatically mounted before you can make modifications to them. We could easily provide example code for doing that if you would like to try it out.

[support]

Hi,

Looks like you are using a relatively old build of OpenOCD. Please try upgrading to VisualGDB 5.4 Preview 5 and install the latest OpenOCD package via VisualGDB Package Manager.

[support]

Hi,

Sorry, this is by design. The “Device-specific files” filter is reserved for the files from the BSP that are automatically managed by VisualGDB. E.g. when you change the MCU type or add/remove frameworks, VisualGDB may replace the entire contents of that filter with the files specified by the current BSP version. The template logic also follows this convention – it stores the device ID and settings and re-creates the contents of device-specific files based on the BSP definition. I.e. if you use the same template with a later version of the BSP, it will still use the correct list of files from the new BSP.

Unfortunately it is somewhat confusing as the “Device-specific files” filter is not shown differently from other filters due to the limitations of the VC++ project subsystem. Long-term we are planning to switch our embedded projects to the Advanced CMake Project Subsystem, so VisualGDB will have fine-grain control over the contents of the Solution Explorer and will be able to clearly show which files are automatically managed by VisualGDB.

[support]

Hi,

Thanks, this looks like a problem that was recently fixed internally. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2443.msi

[support]

Hi,

Strange, the log looks like exactly the same error that was fixed previously is triggering again. Please try again with this build and let us know if the issue is still present: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2443.msi

[support]

Hi,

We have rechecked this and it looks like VS overrides the line endings passed to it by VisualGDB. We will investigate further and will try to add a workaround, however this will be done after the upcoming Preview 5.

As a temporary workaround, please let Visual Studio normalize the line endings when you open the files (or configure git to always commit the specified line ending style if you are using it).

Update: we have found the root cause of it and it traces back to one of the components used internally by Visual Studio [details]. We have tried several workarounds, however they all have considerable negative side effects due to the way VS handles the snippets internally. Hence unfortunately we won’t be able to add any VisualGDB-level workaround for this and would advise relying on Visual Studio or your source control system to automatically normalize line endings, sorry.

• This reply was modified 7 years ago by support. Reason: Pinpointed the root cause

[Author]

Posts