[support]

Hi,

Just wanted to share an update that we have released a new R14 build of the ESP32 toolchain based on the latest MSYS2 environment from Espressif and it looks like the Master checkout of the ESP-IDF now works out-of-the-box. Please feel free to install the updated toolchain via VisualGDB Package Manager.

[support]

Hi,

Good to know it works. Don’t hesitate to get back to us if you run into any further problems.

[support]

Hi,

Sorry, our regular license only includes email/forum support, but we should be able to help you narrow this down.

Please try closing VS, renaming the %LOCALAPPDATA%\VisualGDB\RemoteSourceCache directory and creating a new project using the VisualGDB Project Wizard.

This should re-download all the necessary files and get IntelliSense to work again.

[support]

Hi,

No problem, we will try to clarify. VisualGDB relies on many different 3rd-party tools to handle low-level device access, FLASH programming, etc. The most popular tools for ARM devices are:

• OpenOCD. It’s completely free and actively maintained (e.g. support for ST devices is contributed by ST itself), but may be sometimes buggy or require complex setup.
• Segger J-Link. It is normally designed to be used with the Segger J-Link Pro and other Segger debug probes. The J-Link hardware is more expensive than ST-Link, as Segger maintains a fully supported replacement to OpenOCD that works out-of-the-box with many devices, supports FLASH breakpoints, etc. They also provide functionally limited versions of it that could be FLASHed into ST-Link, but they are normally not covered by their support.

VisualGDB works with both underlying tools, so you can choose one depending on your preferences.

The issue you encountered with Segger software is likely caused by a missing driver, but it’s hard to say for sure. Generally, if you prefer something that works 100% of the time and is fully supported, please consider getting a J-Link Pro.

Alternatively, please try making a copy of your linker script (via VisualGDB Project Properties) and adding the following line before the end of each section:

. = ALIGN(64);

This will align each section to the 64-byte boundary and might solve the problem with the FLASH programming.

 

 

[support]

Hi,

Thanks for reporting this. Looks like a bug of the preview build. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.7.2478.msi

[support]

Hi,

Yes, we have tested our CMake fork on Cygwin. We used the following steps to build it:

1. Install the regular old CMake via the Cygwin package manager. It makes configuration easier as CMake doesn’t need to build a simplified version of itself in order to process its own CMakeLists.txt files.
2. Attempt the regular configuration (mkdir build && cd build && cmake ..). This will report a few missing libraries that can easily be installed via the Cygwin installer. In our tests, the libraries were libncurses-devel and libuuid-devel. You may want to try out the apt-cyg tool to install Cygwin packages from command line.
3. Run “make -j <CPU count> && make install”. That should be it. Ensure that VisualGDB uses the /usr/local/bin/cmake, not /bin/cmake and you are good to go.

[support]

Hi,

Yes, please try installing VisualGDB 5.4 Preview 7 and get the latest version of the GoogleTest framework via the VisualGDB Package Manager. It does include GoogleMock.

[support]

Hi,

It looks like you have upgraded to CMake that does not support the server mode. Are you using the CMake that is shipped with Cygwin?

If yes, please try building it from sources as described here: http://visualgdb.com/documentation/cmake/annotations/

Additionally to enabling the advanced CMake mode, using our CMake fork will let you step through the CMakeLists.txt files, so you will be able to diagnose CMake-related issues faster.

[support]

Just wanted to share an update: we have added a CMake script debugger to VisualGDB 5.4 Preview 7, so you can easily step through ESP-IDF’s CMakeLists to quickly understand what is going on (see the announcement). In our experiments, the project() command is actually redefined by the IDF itself, in a way that does not use the VERSION argument. If it worked under the regular Visual Studio, you might have used a different ESP-IDF build that did not redefine it, or have patched it yourself.

[support]

Hi,

Sorry, this isn’t supported. VisualGDB projects refer to toolchains by unique IDs that are automatically resolved by VisualGDB when you open the project.

The path (neither relative nor absolute) is never hardcoded in the project itself. This allows opening the same project on multiple machines with different toolchain installation directories without modifying anything.

If you want to avoid installing the toolchain on each machine manually, you can simply create a .reg file that will register the toolchain location from your repository on each machine (see HKEY_CURRENT_USER\Software\Sysprogs\GNUToolchains) or rely on the VisualGDB Team Settings mechanism to deploy the toolchain automatically.

[support]

Hi,

If you are using MSBuild, you can override the object file directory for each file using the regular VS properties. Alternatively, please consider switching your project to CMake with the Advanced CMake Project Subsystem. It automatically handles such cases and also builds the projects much faster.

[support]

Hi,

Good to know you have found the download link. Let us know if you need any further help with this.

The build errors might be caused by the Project Properties -> Path Mapping -> GDB Path Style setting. It should be set to “Use toolchain default” in order to automatically switch between Cygwin-based toolchains (R12 and earlier) and MSYS2-based toolchains (R13).

[support]

Hi,

No problem, we will help you get it to work. The problem could be caused by 2 issues: a corrupt toolchain, or incompatible settings cached in the projects.

Please try installing the R12 toolchain and VisualGDB 5.4 Preview 6. Then try creating a new project. If it builds works, please open one of the old projects and check the VisualGDB Project Properties -> Path Mapping -> GDB Path Style setting. It should be set to “Use toolchain default”.

If the old projects still don’t work, please try comparing the .vgdbproj files in a diffing tool (e.g. KDiff3) or simply import the old projects via the ESP32 project wizard to regenerate the settings file.

[support]

Hi,

Please try cleaning the project via Build->Clean All. If it doesn’t help, please remove the toolchain completely and install it again via VisualGDB Package Manager.

It should get rid of any conflicting files and get the project to build again.

[support]

Hi,

Most likely the same source file got included in the project twice (or multiple source files with the same name got included, causing obj file conflicts). The exact steps to fix this depend on your project type, but normally searching for the file name shown in the error message in Solution Explorer should help you narrow it down (ensure that only 1 instance is included in the project).

[Author]

Posts