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

[support]

Hi,

If you are using the Linker Options->Command Line to specify the libraries anyway, you can simply put -Wl,–whole-archive before the library names and -Wl,–no-whole-archive after them.

That said, the recommended way to reference libraries would be to right-click on the executable project in Solution Explorer and select Add->Reference. This will automatically add the libraries to the linker inputs and will also make sure that the libraries are built before the main application. If it helps, we could add a per-library option that will let VisualGDB automatically wrap its name with the –whole-archive/–no-whole-archive when building the linker command line for the main project.

[support]

No problem, we can add an option for wrapping library references with –whole-archive. Just to double-check, are you using MSBuild and referencing the libraries using the regular References window in VS?

[support]

Hi,

The CMSIS-DAP interface is generally very unreliable and slow, so we would recommend simply using ST-Link or J-Link instead.

You might be able to solve the U-Link issue by analyzing verbose OpenOCD log and patching the OpenOCD scripts, however it may not be practical given that ST-Link and J-Link will very likely just work out-of-the-box.

[support]

Hi,

The <VisualGDB>\ProjectTemplates\Linux folder is still present in VisualGDB 5.4 and 5.5 and the underlying logic has not changed much since v5.1.

The custom project templates are still supported, although only with the classic project types (i.e. not with Arduino, Mbed or ESP-IDF). If you believe the path substitution is not working, please share the exact steps to reproduce the issue and we will advise you on the workaround.

Regarding running custom code, it is not possible to run it during project creation, however it is possible to add it as a custom shortcut (VisualGDB Project Properties -> Custom Shortcuts) that will be available via the Project menu in Visual Studio. You can create a shortcut for the initialization commands that should be run after creating the project from the template and then run it after creating the project from the template.

[support]

Thanks for renewing your support.

If the firmware doesn’t start completely, we would advise checking the following points:

1. Using Embedded Memory Explorer, check that the interrupt vector is present at the correct address (double-check the address in the device datasheet, or compare it with a working file).
2. Double-check that the interrupt vector points to the correct Reset handler function. You can dump the contents of the section containing the interrupt vector by running arm-none-eabi-objdump or do it at runtime by evaluating *((void *)0xADDRESS) via the Watch window.
3. You can configure VisualGDB to stop at the Reset handler via VisualGDB Project Properties – >Embedded Debug Tweaking and then starting debugging with F10 instead of F5.
4. If nothing helps, you can also try hardcoding a breakpoint in the reset handler (asm(“bkpt 255”)) and issuing a manual reset via the GDB Session window (mon reset).

[support]

Hi,

It looks like your support period has expired. Please renew it here and will be happy to help you.

[support]

Yes, please refer to the following tutorial for details: https://visualgdb.com/tutorials/arm/semihosting/

[support]

Hi,

Yes, you can configure VisualGDB to extract the memory layout from your custom linker script.

Please try using the latest VisualGDB 5.5 Preview 2, open VisualGDB Project Properties on the Additional Memories page. The setting on top of the page controls whether VisualGDB will use the memory definition shipped with it, or will extract it from the linker script.

[Author]

Posts