[support]

Based on your description, the project you are importing has up-to-date build scripts for GNU Make, but the CMake scripts are missing references to the .a files (CMake projects built with idf.py take settings from CMakeLists.txt and ignore the .mk files).

You can work around this via one of the following options:

• Simply import the project as a GNU Make-based project instead of CMake. This can be accomplished by renaming/deleting the CMakeLists.txt file from the imported project directory when importing it with VisualGDB.
• Copy the library names from the .mk files to the CMake settings. VisualGDB can edit them automatically via VS Project Properties for the project, or you can use the variables described in the ESP-IDF CMake Reference.

[support]

Thanks for the update. The CMAKE_HOME_DIRECTORY error would happen if you had previously built the sample project in-place with different CMake settings (normally, VisualGDB would not do it when using the “new project based on sample” mode in the wizard). Either way, doing a rebuild should clear out any cached files.

VisualGDB indeed does some background work when you open the Debug Settings page of VisualGDB Project Properties – it scans for the connected USB JTAG probes and ensures you can select a different one.

We have tried using different delays (anywhere between 1 and 10 seconds), but unfortunately still could not reproduce it. If the problem happens again, please try creating a video showing:

• The entire VS window (specifically, the Output -> Advanced VisualGDB Project pane) so that we could see the status of the background project load.
• The process of opening VisualGDB Project Properties, making the change, closing the window and opening it again to get the incorrect value.

You do not need to record the creating of the project, as the settings picked in the wizard that might affect the device selection are clearly visible from the Debug Settings page.

[support]

Thanks for confirming your license status – we have linked it to your forum account in our system.

The hardware breakpoints in user-mode code might be supported (the kernel implement them via register_user_hw_breakpoint()), however we did not research whether gdb/gdbserver is capable of using that interface. You should be able to find it our by looking through the gdbserver source code – there might be a configuration switch enabling them.

If you can find a combination of tools that does support hardware breakpoints, we can easily add the button for toggling them to VisualGDB. However, if no underlying tool supports this scenario, unfortunately VisualGDB won’t be able to work around that.

[support]

Sorry, it’s hard to suggest anything specific based on the description you provided.

[support]

Sorry, we have tried reproducing this on a basic ESP32 project (opened VisualGDB Project Properties, changed the frequency to 4000, pressed OK) and it got applied correctly.

Most likely the issue is triggered by some specific combination of settings in your project. If you could share the screenshots of each related step (i.e. project properties before/after and also the Solution Explorer so that we could see the project type) and let us know what exactly you are changing and in what order, we should be able to fix this.

[support]

Thanks for the update. In this scenario, the difference might indeed come from software/hardware breakpoints. You can double-check this by running the “hbreak” command from the GDB Session window to set a hardware breakpoint manually.

VisualGDB would manage the hardware breakpoints automatically for JTAG-based debugging sessions, but it does rely on the GDB itself to handle it when debugging Linux processes. We could also add a toggle button to the GDB session window that will switch to using hardware breakpoints each time you create a new breakpoint via the Visual Studio interface to facilitate your scenario, although that would require purchasing a VisualGDB license (if you already have one associated with a different email address, please let us know).

[support]

In order to determine for sure whether this can be hotfixed on our side side, we would need to do a detailed profiling of this scenario on our side, however as creating new threads every 5ms doesn’t usually happen during typical debugging scenarios and as other components (i.e. GDB) also appear to be hitting the bottlenecks, we won’t be able to do the advanced investigation of this, unless it can be reproduced in a more typical debugging scenario where gdb itself is still responsive and is not using all of the CPU sending thread events (and hence likely not be able to respond to VisualGDB).

[support]

Good to know it works. Espressif did previously mention that the CMake build scripts are missing some of the advanced features supported by their Make scripts, so it makes sense. Either way, VisualGDB does and will support both build systems, so that you can always find the one that works.

[support]

OK, we have fixed the issue in VisualGDB 5.4R4. You can download the new version here: http://visualgdb.com/download/

[support]

Sorry, it is not supported. We might be able to add it in one of the next versions of VisualGDB but it’s hard to give any estimates at this point as it would require non-trivial changes on our side.

[support]

Thanks for the update, this makes sense. If you had previously selected -O0 in the regular VS Project Properties and -O2 in the stand-alone project properties, indeed the behavior would change in v5.4R3.

We had to change this because the previous logic did not provide an easy way to override the default settings provided by VisualGDB for regular (non-standalone) projects.

Generally, we would advise using the stand-alone project properties for device-specific flags (e.g. specific preprocessor macros, FPU type, etc) and the VS Project Properties pages for general C/C++ settings (optimization level, warnings, debug information). If this is not possible due to any reason, please let us know and we will help you find a workaround.

[support]

Thanks for pointing this out. It turned out to be our bug – in the recent V5.4R3 update we optimized the initialization logic of VisualGDB: instead of loading during Visual Studio startup, it would only get initialized once a VisualGDB-based project is loaded, or any of the VisualGDB-related commands is used. It turns out, when loading the multi-project solutions via command line, Visual Studio sent some of the project load events in a slightly different order, that caused VisualGDB to miss some of them.

We have fully fixed the issue in the following build: VisualGDB-5.4.103.3022.msi

Sorry for the inconvenience and thanks for providing sufficient details for us to reproduce the issue.

[support]

Thanks for the update. We understand your frustration with this and we do apologize for the inconvenience this have caused, however since there are many different ways in which the VisualGDB projects could specify various build flags, it is hard for us to provide a hotfix for this without either seeing the original .props/.xml/.vcxproj files, or getting the exact repro steps that we could run on our side in order to reproduce the behavior. The good news is that once we can reproduce it on our side, we should be able to fix in about 1 day.

[support]

Thanks for the update. This is likely a side effect of changing the order in which the MCU-specific property sheet is applied. We have changed the order so that the values from the VS Project Properties would override the default values derived from BSP.

Most likely you have manually defined some of the flags in a way that we did not expect and hence they are getting overridden as well.

If you could post here (or send us via the support form) the mcu.props, mcu.xml and the .vcxproj file, we should be able to reproduce this quickly and make the necessary adjustments on our side.

[support]

Good to know you found the root cause. If you encounter further problems, please don’t hesitate to create another thread.

[Author]

Posts