[support]

Hi,

Our ARM toolchain is based on the same sources as the official GNUARM toolchain (specifically, the 9-2020-q2-update release). The only difference from the original toolchain is that we rebuilt it with big endian support.

Please refer to the official GNUARM documentation for specifics on supported libraries, versions and features.

P.S. We are also working on an updated toolchain build based on 10.3-2021.07, however, it is also directly based on the GNUARM toolchain sources and will work exactly the same as it.

[support]

Hi,

Unless the project contains all the necessary files so that we could build it and observe the same behavior as you have, it’s hard to suggest anything specific.

Please try updating to VisualGDB 5.6 Beta 4. If the problem persists, please try uploading the entire project to a file sharing service (e.g. Dropbox/OneDrive) and posting the link here.

[support]

Thanks for the detailed repro steps. We have tried reproducing it on our side, and got the “../” paths in the build log, however clicking on them worked as expected.

Please try updating to VisualGDB 5.6 Beta 4. If the problem  persists, please try attaching a .zip archive with the faulty project so that we could recheck it on our side.

Also, as a side note, moving the project like this would break the connection to the BSP folder, and might interfere with some of the functionality (although not the build log navigation).  A much easier way to accomplish it would be to already create a project in a subdirectory (e.g. c:\projects\name\Solution) and use “..\BSP” instead of “BSP” when converting it to a stand-alone one.

Also, please consider switching to the Advanced CMake Project Subsystem. It is designed to specifically address the shortcomings of GNU Make and MSBuild, and generally works much better, while allowing you to build the projects outside VisualGDB as well.

[support]

Hi,

Most likely, you have selected some combination of settings that breaks either the VisualGDB formatting logic, or some other extension.

First of all, please double-check that you are using the VisualGDB’s Clang IntelliSense, and also recheck whether you are using Clang-format or Sysprogs Formatting Engine as described here.

If you are using Clang-format, please share your .clang-format file so that we could recheck what is going on.

If you are using SysprogsFormat, please try resetting all VS-level settings via Tools->Import and Export Settings (you can save them beforehand). If it doesn’t help, please try renaming the HKEY_CURRENT_USER\SOFTWARE\Sysprogs\VisualGDB\Settings\CppEngine key in registry.

If this fixes the problem, please try restoring the original settings one-by-one. If you can point to a specific combination of settings that triggers this problem, we will be happy to investigate it further.

[support]

Hi,

It looks like you are using an older version of Visual Studio and VisualGDB.

Please try updating to Visual Studio 16.11.1+ and VisualGDB 5.6 Beta 4.

[support]

No problem. If the problem can be reliably reproduced on a cleanly created project, please try packing it into a .zip file and attaching it here so that we could try to reproduce it on our side.

[support]

Hi,

This would happen if the project contained manually defined path mappings that would map correct paths into incorrect ones.

Please try resetting mappings via VisualGDB Project Properties -> Path Mapping.

If it doesn’t help, please try reproducing the problem on a project created from scratch. You can simulate the build output by overriding the build command with “cmd /c type $(ProjectDir)\log.txt” where log.txt is a text file containing the previously captured log.

[support]

Hi,

Indeed, the Arduino projects do not have the GUI for changing the hardware register definition file. However, you can always roll it back by removing the MCUDefinitionFile element from the .vgdbproj file, and reloading the project.

We also advise checking in your project into source control, so that you could track the changes and easily roll them back in case something breaks.

[support]

Hi,

The latest v5.6 Beta 4 should work just fine (other than a glitch with VS2022 Preview 2). If not, please try the latest development build: VisualGDB-5.6.5.4280.msi

If it doesn’t help either, please let us know more details and we will help you get it working.

[support]

No problem. SysprogsSync is faster and more efficient than tar or rsync, as it only downloads the mismatching files and also handles complex symbolic links correctly. However, if it doesn’t work, VisualGDB can always fall back to the legacy mechanisms.

If using tar gets the folder synchronized correctly and using SysprogsSync doesn’t, we can help you get it to work as well, as long as you can provide more details. I.e.:

1. Specific files that got synchronized with tar and did not get synchronized with SysprogsSync.
2. A relevant SysprogsSync.log file so that we could recheck whether they were read correctly.
3. Any relevant details about these files (e.g. they are inside another mounted volume or have special access rights).

[support]

Sorry, we do not support it yet. However, we do support the Nucleo-H743ZI board.

[support]

Sorry about that, it was a typo. Indeed, the file is called edp.xml and not bsp.xml.

[support]

Hi,

Thanks for the detailed repro steps. Indeed, the STM32MP1 fork of OpenOCD is designed to not be displayed for regular projects in order to avoid confusion.

You can work around it by removing the BSPFilter element in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd.stm32mp1\bsp.xml file and restarting Visual Studio.

[support]

Hi,

Please try restarting Visual Studio. If it doesn’t help, you can disable the advanced build window completely via Tools->Options->VisualGDB->Advanced Build->Show build output from VisualGDB projects in = Regular Build Window.

[support]

No problem. Please try disabling SysprogsSync for this host via Tools->VisualGDB->SSH Host Manager. This will revert to using tar.

[Author]

Posts