Forum Replies Created
-
Posts
-
Hi,
Sorry, based on your description, it looks like the slowdown comes from gdb itself processing the thread events (that is outside VisualGDB’s control) and VisualGDB/Visual Studio processing the excessive GDB output. E.g. each time VisualGDB reports a new thread to Visual Studio, it would update multiple internal structures (and the Threads window if it’s open) and it was likely never designed for the “new thread every few milliseconds” scenario.
Although we could optimize VisualGDB to reduce its impact on the slowdown, given that this scenario is unlikely for regular debugging and that both GDB and Visual Studio contribute heavily to the slowdown, it would likely not improve the GUI responsiveness, sorry.
Hi,
Thanks for reporting this. We have tried reproducing it on a clean project, however we could not get the behavior you described.
Please try checking if the problem can be reproduced on a clean project on your side. If yes, please let us know the ESP-IDF version you are using. If not, please try comparing your project with the clean project, as the issue might be triggered by some small change that is only present in your project.
Thanks for updating your forum email to match the license email.
We have reviewed the patches, however we do have some considerations about them. It looks like instead of creating a new driver from scratch, or adding minimal changes to the existing driver, the patch author introduced many changes across the existing STM32L4 driver, extending it to cover the STM32G0 family as well.
Unfortunately, this means that if any of those changes introduce bugs, it would make OpenOCD unusable for some of the existing STM32L4 users, and since many of our users rely on the existing STM32L4 support, we won’t be able to merge those patches to our OpenOCD fork unless their reliability is confirmed (typically, once the patches are included in the mainline OpenOCD repository, we consider them verified by the OpenOCD maintainers).
That said, there are several workarounds:
- First of all, please consider checking out and building our OpenOCD fork (see the detailed tutorial). We have specifically made it easy to build (by converting it to CMake) and provide a ready-to-use toolchain that can help you compile it by simply opening the project file in VisualGDB and building the solution. Then you can try merging the patches into it and replace the OpenOCD.exe file under %LOCALAPPDATA% with the version you build. We can help you get our OpenOCD fork to build and run, however we cannot guarantee that the patches can be merged easily, or that they will work at all.
- If anyone restructures the patches to be completely separate from the STM32L4 family (it can be done by just copying the existing driver and renaming the references), we can merge it into our tree. As long as it doesn’t interfere with the device families that are already supported, we are happy to include it as long it works with at least some of the devices in the new family.
- As another alternative, please consider using Segger J-Link. It is more expensive than ST-Link and FT2232-based probes exactly because they maintain a proprietary replacement to OpenOCD that is frequently updated and tested with the newest devices, so you don’t need to worry about that.
Thanks for the screenshot. This path is indeed automatically derived from the build-level settings and cannot be changed. We will consider showing it in a different color in one of the next VisualGDB releases to avoid further confusion.
As a workaround, please disable deployment on the Debug Settings page and try adding a custom action for uploading the stripped file via pre-debug actions.
No problem, please let us know the email associated with your license key so that we could link it to your forum profile and we will walk you through diagnosing this.
We usually include the patches once they are become a part of the mainline OpenOCD source tree.
If you would like to have them included earlier, please consider applying them on your side to our OpenOCD fork, confirm that it works on the hardware and send us a merge request.
If you have purchased a license and have an active support coverage, we can also do it for you. As long as the patches are readily available and do not require non-trivial merging, this is covered by our support.
The contents of the Solution Explorer window is reconstructed from the project structure reported by ESP-IDF, so in order to understand what is going on, we would need to see a snapshot of that structure.
Please let us know if you are using GNU Make or CMake and we will provide you with instructions to obtain the snapshot.
Yes, please try running msbuild with the -verbosity:diag switch and either attach the diagnostic log here, or send it via our support form. It should explain what is going on.
Hi,
Sorry, this is a known limitation of VisualGDB. It offers numerous debug-time tool windows that provide various insights into the state of the target and the debug session, however this only works when only one VisualGDB-based debug session is active at the same time. As a workaround, please consider splitting your solution into multiple ones.
Thanks for the update. This looks like a different issue. If the breakpoint circle is hollow inside, the code where the breakpoint is set is not a part of the debugged binary (e.g. it is not actually called from any other code and was hence discarded).
You can double-check this by inserting the following line into the functions that don’t seem to work:
asm("bkpt 255");It will trigger a breakpoint each time the line gets executed. If it doesn’t happen, the function is actually not called and using the “find references” command should help understand why this happens.
If the breakpoint does trigger and you see the “bkpt 255” instruction in Disassembly, but the source code doesn’t appear, the problem is due to missing/mismatching debug symbols. If this is the case, we can provide more detailed instructions on diagnosing it.
Hi,
Please simply set the breakpoint before starting debugging with F5 and VisualGDB will be able to handle this automatically.
You can also modify the behavior of the “Step into new instance” command (F10 instead of F5) to stop as soon the program is loaded into the MCU (i.e. at the reset handler) via VisualGDB Project Properties -> Embedded Debug Tweaking.
Normally, the sdkconfig.h file should be handled by the ESP-IDF build system itself. The only advice we could give is to try creating a project based on GNU Make instead of CMake (it uses a different set of build scripts) and if it doesn’t work either, check if the problem can be reproduced by building from command line.
If it doesn’t work from command line either, please check with Espressif – it might be a bug on their side. If it works when built manually, but fails under VisualGDB, please let us know both build command lines and we will investigate.
Thanks for the update. The behavior you described actually makes sense. The latest v5.4R3 update changed the way VisualGDB is loaded into Visual Studio. Instead of loading at startup (slowing down the Visual Studio load time), it will only fully load once you use any of its menu commands, or open a VisualGDB-compatible project.
Most likely, the project in question is modified in a way that prevents the VisualGDB loader from recognizing it and hence fully loading the VisualGDB extension. If you could attach just the .vcxproj file (or send it to our support in case it’s confidential), we should be able to see why it is not recognized and update VisualGDB to handle it properly.
