[support]

Sorry, looks like there is some misunderstanding going on. Based on your initial question we assumed you were looking for VisualGDB to remember the state of folded code blocks between the sessions (that is not supported).

Just code folding and region folding is a part of VisualGDB and is supposed to work, although it could break if the Clang IntelliSense could not get the necessary information from the low-level Clang logic. We can help you get it to work, however we would need to know the following details about the problem:

• What is the exact project type you are using (Embedded/Linux/ESP-IDF/Arduino/etc)?
• Does the code folding work for a freshly created project of the same type?
• If not, does it work for a freshly created MinGW project (VisualGDB Windows project wizard).

It would also help to see the screenshots illustrating the problem (or a short video demonstrating the problem).

Generally, as VisualGDB includes numerous features and settings, in order to avoid misunderstandings, please consider using the following structure when describing the issues:

1. What exact steps you take (from starting VS, not including any existing projects).
2. What do you expect to see.
3. What do you actually observe.

E.g.:

1. Start VS. Create a new Embedded Project Wizard with STM32. In the main file enter the following code:

   void testfunc()
   {
       if (1)
       {
           if (2)
           {
               
           }
       }
   }

2. Expected behavior: the “collapse” box should appear near “testfunc”
3. Actual behavior: the box doesn’t appear

This will help us quickly distinguish the problem from many similar issues that could have completely different causes and get back with a fix or a workaround promptly.

[support]

As mentioned in our previous reply, 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 linking your forum profile to your key. The GDB stub functionality has actually been greatly improved in the ESP8266 2.5.0 core (in the previous versions it was barely usable), however due to some changes to the internal layout, you would need to install VisualGDB 5.4R3 or later (we recommend the latest R4) and ensure you have the latest ESP8266 Arduino core and the latest ESP8266 debug package installed (you can install both via Tools->VisualGDB->Manage VisualGDB Packages).

Then try creating a new Arduino project and ensure you can build and debug it (VisualGDB will set the GDBSTUB_BREAK_ON_INIT=1 variable via VisualGDB Project Properties). Then, simply copy the gdb stub-related code from that project to your project and you should be able to use it.

If gdbstub.h file is empty, it might have been simply corrupted by something else. Deleting and reinstalling the component providing it (if you are not sure, please let us know the full path to that file) should normally resolve it.

If you are not using Arduino, please let us know the exact toolchain and project type you are using (MSBuild, Make, or the new RTOS SDK 3.0 that comes with its own build system) and we will help you get it to work.

[support]

No problem. As long as the problem is caused by one of the VisualGDB components and we get enough details to reproduce it on our side, we are usually able to fix it very quickly.

[support]

No.

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

[Author]

Posts