[support]

Hi,

The most common cause of this issue would be another dialog window opening up in the background. Due to WinForms/WPF interop issues, dialog windows sometimes appear underneath the regular VS window and are hence not visible. Please check the task list (Alt-Tab) and the VS icon in the Task Manager to see if there are any extra dialog windows (e.g. confirming some missing tools).

If it doesn’t help, please try updating to VisualGDB 5.5 Preview 3 and let us know the exact project type you are creating (Embedded/Linux/etc; CMake/MSBuild/GNU Make) and also whether the problem triggers for other project types. Also please share a screenshot and a call stack or the frozen VS instance once it freezes for about 1 minute or more.

[support]

Hi,

Yes, please use the following setting: VS Project Properties -> General -> General -> Generate a test container file = Yes.

Note that this setting is stored separately for Debug/Release configurations, hence you need to update it for every relevant configuration.

[support]

Hi,

Based on the description you provided, everything should work. Hence the problem is likely caused by some small detail that was omitted from the description. Please share the screenshots of all the relevant settings (including the exact error message you get) and we will help you understand what is going on. If you do not wish to post them publicly, please consider sending them via our support form instead.

[support]

No problem and good to know it works. If you encounter any further problems, feel free to get back to us.

[support]

Sorry, CMake-based projects currently only support the predefined set of configurations (such as Debug, Release, etc). In order to create multiple debug configurations, please consider creating multiple VisualGDB projects (.vgdbcmake) wrapping the same CMakeLists file. Then you can set additional per-project CMake definitions via VisualGDB Project Properties.

[support]

No problem, please try this build: VisualGDB-5.5.3.3461.msi

We have also added a checkbox in the Export Template window that allows automatically replacing the exported project’s name with $$PROJECTNAME$$ in file names and contents.

[support]

No problem, please try this build: VisualGDB-5.5.3.3461.msi

We have added the following option: VS Project Properties -> Exported Settings-> Link as Whole Archive (needs to be set for the library). After you set it, next time you build the main project, VisualGDB will automatically inject the –whole-archive option into the linker command line (see the .link.rsp file). Note that if you don’t change any other files after applying this option, it won’t trigger a rebuild of the main project.

[support]

Thanks for checking everything. The memory utilization computation was the last fix that went into Preview 3, hence it is indeed only present in that specific build.

If you are using GNU Make, the build results should normally be completely the same, since all VisualGDB does is launches make.exe in the project’s directory.

In order to troubleshoot it, please do the following:

1. Try comparing the fast and slow build logs. Is there any difference? Does VisualGDB 5.5 consistently rebuild all files, while VisualGDB 5.4 only build changed files?
2. What happens if you run VisualGDB.exe /build … (see the VS Output window for the full command line) manually from the Command Prompt? Is the build still slow?
3. What happens if you run make CONFIG=Debug (see the VS output window for the command line again) in the project directory (you may need to set BSP_ROOT and TOOLCHAIN_DIR via environment)? Does it also build slowly?

[support]

Hi,

Most likely, you are using VisualGDB with clang-format. Please try clicking on the “format document” icon in the top right corner of the text editor (near the “go” button). It will open a detailed editor for the clang-format style file.

[support]

Hi,

Strange, the build-related logic of VisualGDB 5.5 has not changed compared to 5.4 (with the exception of the new build output window).

If you can confirm that installing v5.4 back increases the build speed, please try disabling the advanced build output (Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB = Regular VS Output Window) and restarting Visual Studio. If it helps, please let us know and we will investigate what could be causing the slowdown. If it doesn’t help, please let us know if you are using GNU Make or MSBuild and also try checking if disabling the antivirus speeds up the build.

Thanks for pointing out the memory utilization bug, it was indeed shown incorrectly for adjacent memories. We have fixed it in VisualGDB 5.5 Preview 3.

[support]

Thanks for pointing this out. We have updated the OpenOCD script selection rules to automatically pick the single-bank script for single-bank devices.

You can get the new rule file by reinstalling the OpenOCD package via Tools->VisualGDB->Manage VisualGDB Packages.

[support]

Hi,

Keil might have protected the memory with the fuse bits in a way that cannot be overridden by OpenOCD.

Either way, feel free to troubleshoot it on your own if you have a better understanding what is going on. If not, please try erasing the memory using the ST-Link tool and then use the “Verify FLASH memory” button in the GDB Session window to see what exactly got programmed into the FLASH memory. This should help narrow down the issue and help us suggest next steps.

[support]

Hi,

Perhaps the FLASH memory is locked via the fuse bits? Please try completely erasing it via the ST-Link tool.

[support]

Thanks for the explanation. VisualGDB 5.4+ still uses the templates under <VisualGDB>\ProjectTemplates, however instead of showing a plain list of templates in the wizard, it allows automatically picks the best template based on the project type/build subsystem choices. As a side effect, this indeed makes it impossible to add custom templates via this mechanism.

We have updated the logic that handles the .vgdbxpt files to substitute the $$PROJECTNAMEBASE$$ and $$PROJECTNAMEBASE_CPPID$$ variables. VisualGDB will also substitute those values inside the files that have the SubstituteProjectName property set to true in the template.xml file (re-create the template using the VisualGDB build below to see the new property).

Please try this build: VisualGDB-5.5.3.3457.msi

[support]

Thanks for pointing it out. We have quickly rechecked the default project generated for the STM32H750IB  device and it appeared to be fine (we don’t have this specific hardware to test it). Hence, the problem you are experiencing might be caused by one of the following issues:

1. The layout of the project built by VisualGDB doesn’t match the target (e.g. you selected a slightly different device when building the project or there is a bug in our device definitions).
2. Something is interfering with the debugging (e.g. unstable power).

The easiest way to narrow this down would be to try using VisualGDB to debug an application for the same board built with the ST’s IDE:

1. Try building a similar project in the other IDE and locate the .elf file.
2. Copy the elf file over the one built with VisualGDB (<Project directory>\VisualGDB\Debug\<Project Name>).
3. Select Tools->Options->Projects and Solutions->Build and Run->On Run->Prompt to Build.
4. Start debugging. When Visual Studio asks whether to rebuild the project, click “No”.

Please let us know if a project built outside VisualGDB runs as expected under the VisualGDB’s debugger and we will advise you on the further steps to diagnose this.

As a quick alternative, you can also try configuring VisualGDB to stop at the reset handler (VisualGDB Project Properties -> Embedded Debug Tweaking) and press F10 instead of F5 to start debugging. This will step into the very first instruction that gets executed after reset, letting you debug the initialization code.

[Author]

Posts