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

[support]

Thanks for the update. If you encounter any further issues, please do not hesitate to get back to us.

[support]

Sorry about that. This is strange, as we have not changed the logic related to the CFLAGS in v5.4R3, however it might be a side effect of some other change.

We can help you resolve this if you could let us know the project type (Embedded/Remote Linux/Cross-compiled Linux), the build system (Make/CMake/MSBuild) and also give a specific example of the command line you get, command line you expect and the entire .mak/.props/.vcxproj file where the flags are defined (if you are not sure, we can provide more details once we know the project type).

[support]

Sorry about that. We have already fixed it in this build [VisualGDB-5.4.103.3020.msi] and will release R4 including the fix in the next few days.

[support]

Hi,

Most likely, the original project contains some special settings that were not automatically imported.

The easiest way is to narrow this down to a specific source file and then compare the build command lines used by the Keil IDE and by VisualGDB. You can find the VisualGDB’s command lines in the .rsp files inside <project directory>\VisualGDB\Debug. The command lines from the Keil IDE can be found by enabling the .bat file generation and looking through the generated file (it will use the –Via <filename> syntax where <filename> will correspond to the response files generated by Keil).

Once you find out a specific command-line argument, we can help you locate the corresponding VisualGDB setting.

[Author]

Posts