[support]

The IT instruction might not be supported by your device. Please double-check its documentation to be 100% sure.

[support]

No problem. The IntDir might have been set in a different order then (i.e. before VisualGDB computes the paths of some intermediate files). Either way, we have added the checks for this case in the new build, so unless you encounter further problems, the project should be good to go.

[support]

Thanks for the project file. We have tried reproducing this on our side, however could not get the behavior you described, so we added more logging to the related logic in VisualGDB.

Please try this build: VisualGDB-5.4.103.3019.msi

Please open your project, confirm that the menus are still not shown, then click Help->About VisualGDB to force VisualGDB to load. Once it is loaded, open View->Other Windows->VisualGDB Diagnostics Console and enable the logging. The console will already have the output from the project load hook. Please share it here and we will be able to see what is going on.

[support]

Thanks, looks like your project did not have the $(IntDir) variable set and that triggered an unexpected path format inside VisualGDB. We have added a check for it in the following build: VisualGDB-5.4.103.3019.msi

[support]

Hi,

Most likely the library mentioned in the error message is either corrupt, or is not installed in the correct path. Please try ignoring the error and proceed to debugging the project.

If the error reoccurs, please try using the View->Other Windows->VisualGDB Diagnostics Console to see the exact command line used by VisualGDB to start debugging and then try running it manually via SSH. If the problem can be reproduced, please double-check LD_LIBRARY_PATH variable and the actual .so files present in the path directories.

[support]

Hi,

The previous versions of VisualGDB would still try to guess the IntelliSense parameters for the files that are not directly compiled, but would indeed not show the warning.

Either way, we can help you pinpoint this. Please identify a specific source file that triggers the problem and take a note of its full path (right-click on the document tab header and select “copy full path”). Then open View->Clang IntelliSense Diagnostics Console, switch it to the Project Structure view and check if the file is listed there with the exactly the same path. If it is not and you are not sure why, please share more details about your project (project type, what files from the project are listed, what are not, etc.).

Please also try reducing the solution to just 1 project (ensure you reload it afterwards) – it should make diagnostics easier.

If the problem only happens for header files, please let us know and we will share updated instructions.

 

[support]

The version shipped with VisualGDB was also downloaded from the official Ninja site, although it’s likely a different version.

[support]

Thanks for clarifying this.

It might be caused by some recent changes in the v3.3 codebase (we have checked it with a v3.3 checkout made earlier and could not reproduce the problem). Given how fast Espressif adds and deprecates various internal structure changes, we will have to wait until v3.3 is officially released before we can fully support it on our side.

As a workaround, please consider editing CMakeLists files manually.

[support]

Thanks for sharing this. Segger usually does a pretty good job at being up-to-date with the latest devices and protocols and it’s good to know they now support STM32G0 as well.

ST will likely contribute some level of STM32G0 support to OpenOCD in the next few months, but Segger usually starts supporting new devices faster.

[support]

You should be able to do this by reusing the build command line shown in the VisualGDB build log (you can find the CMake parameters in View->Output->Advanced VisualGDB Project Output when opening the project), however you may need to setup some additional environment (e.g. cmake/ninja paths).

[support]

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.

[support]

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.

[support]

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:

1. 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.
2. 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.
3. 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.

[support]

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.

[support]

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.

[Author]

Posts