[support]

This looks like a known OpenOCD bug that sometimes triggers on STM32L0 and L4 devices.

The easiest workaround would be to switch to Segger J-Link that comes with its own FLASH programming logic. Alternatively, please try experimenting with section sizes and alignment – the OpenOCD bug is usually triggered by small sections.

[support]

Thanks for the repro. We have reproduced and fixed the issue in this build: VisualGDB-5.4.104.3039.msi

[support]

Hi,

This doesn’t look like any known issue. If you could share a sample project that would allow reproducing the issue on our side, we should be able to fix this.

[support]

Sorry, unfortunately it is hard to suggest anything specific without the exact steps to reproduce the problem. Please try comparing the setups where the code folding works vs. where it doesn’t and try checking if some specific setting, or some specific sequence of steps triggers the problem. Unfortunately, without having specific steps to reproduce it on our side, we are not able to locate the root cause of the problem and fix it.

[support]

Thanks for the detailed description. The error looks like a race condition between ending the GDB session and cleaning up the breakpoint. It should normally not interfere with the rest of debugging.

Either way, we have fixed it here: VisualGDB-5.4.104.3035.msi

If the breakpoint still does not trigger, please share a gdb session log file and also the output from View->Other Windows->VisualGDB Diagnostics Console along with more details (the path of the .py file where you try to set the breakpoint).

Please also let us know if the Python frames in the Call Stack are shown correctly (i.e. with code locations) when hitting a breakpoint in the C++ module.

[support]

No problem. It is most likely caused by some sort of a race condition, so it’s hard to narrow it down without being able to reproduce it reliably, or at least having some clues from the video.

Either way, if you encounter the problem again (or if anyone else encounters it), please feel free to share a video and we will be happy to look deeper into this.

[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/

[Author]

Posts