Forum Replies Created
-
Posts
-
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Hi,
This is to be expected. VisualGDB manages toolchains and BSPs by generating %LOCALAPPDATA%\VisualGDB\FindXXX.props files that have a structure like this:
- If (ID = ‘xxx’ and VERSION = ‘yyy’)
- Include <toolchain-specific .props file>
- If (…)
If you are running MSBuild from a different user account, the files will not be present in %LOCALAPPDATA%, and MSBuild will not load the correct toolchain properties.
The easiest workaround would be to simply run the Jenkins task from the same user account (in Jenkins parameters, or using runas). This will automatically pull toolchains, BSPs, licensing information, etc.
If you absolutely have to use another account, you would need to manually copy the .props files (and possibly, other files like the test frameworks). These files are located under %LOCALAPPDATA%\VisualGDB, so copying the entire directory could be a good starting point.
You can also configure VisualGDB to generate batch files for unattended building as shown here. This way, the projects can be built in the test environment without having to install VisualGDB there.
OK, thanks for your patience. The 6.1 release is out, so we are back to adding new features.
Currently, switching between the projects works out-of-the-box, as long as they are separate projects on the Visual Studio level (e.g. MSBuild, Legacy GNU Make). The GUI for switching is similar to the regular Visual Studio’s one:
It will not work for Advanced CMake projects where the same file would be reported by multiple targets within the same project. If you need support for this case, let us know and we will add a special check for this.
Hi,
No problem, we should be able to add a setting for this. We are currently running the final tests on the 6.1 release and will look into this soon after. We should be able to post an update in about a week.
No worries. BTW, the other STM32 packages passed the remaining tests and have been released as well.
We also caught a glitch in the CMake logic of v6.1 that would interfere with the default FreeRTOS port selection. It has been fixed in this build: VisualGDB-6.1.101.5501.msi
No problem and thanks for your patience.
We have just released an updated BSP for STM32H7RS. You can install it via the VisualGDB Package Manager as usual. We would also recommend updating to this VisualGDB build: VisualGDB-6.1.101.5500.msi. It’s the release candidate for v6.1 that has been tested with the new BSPs.
We also released updated ARM toolchain (GCC 15.2) and updated OpenOCD (regular + ST fork). Packages for the other STM32 families will be released tomorrow, after they pass the final test run.
No problem. In our experience the GNU demangler is a few GCC releases behind the GCC itself. So, there’s a good chance that it will work better with GCC 16.0 or 17.0. You can try checking c++filt whenever a new GCC release comes out, and if it works better, we can easily rebuild our demangler using the same gcc version.
Hi,
Sorry for the delay. There is no automatic way to update the project to an arbitrary GitHub version of the HAL. You can convert the project to a fully-custom one, and manually replace the relevant files, but it is not guaranteed to work and may require some manual adjustments.
Automatic one-click updates work for the HAL versions that have been tested by us and released as BSP packages. We are working on a major update to the STM32 BSP system that separates the BSPs for different device families (e.g. STM32H7 vs F4), resolving many glitches caused by slightly different versions of FreeRTOS, AzureRTOS, etc. between the device families. We were originally expecting to release the update yesterday, but there are still a few glitches left to fix on our side. Unless we discover anything completely unexpected, the BSPs should be ready to download in the next couple of days.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
No problem. Could you please check whether it works with the c++filt.exe executable from our latest MinGW toolchain?
If not, does it work with any other c++filt version?
Hi,
Normally, the quick info mode should not affect reparse times. We have just rechecked it as follows:
- Created a new project from scratch (Embedded STM32, Advanced CMake)
- Enabled Clang IntelliSense Diagnostics Console
- Tried adding one empty line at a time to the main source file, observing the diagnostics console for reparse messages (Starting operation: Parse)
- Triggered a Quick Info popup and switched it to References
- Closed the popup and tried adding empty lines again
In both cases, the file is reparsed whenever you make a large enough break between adding new lines (or when you explicitly save the file). To be more precise, VisualGDB keeps a track on how long it took to parse the file last time, so it waits until there are no edits to the file for 5x the last parse time before it triggers another parse. It should not be related to Quick Info, but can appear inconsistent if the parse time varies between iterations.
Either way, you can fully tweak this behavior via Tools->Options->Text Editor->C/C++ (VisualGDB) -> Adaptive Reparse. E.g. set the additional delay, or the minimum reparse interval.
OK, we have rebuilt the demangler DLL based on GCC 15.2, and also updated our MinGW toolchains based on that version.
Feel free to try this build: VisualGDB-6.1.101.5494.msi
Hi,
OK, we got through the backlog and released the updated versions of both the 32-bit and the 64-bit toolchains.
Hi,
Based on what we see, your support has expired. We are currently working on several other updates requested by paid users, and do not have a timeline for STM32N6.
Please consider renewing your license if you would like to get a time estimate.
Hi,
No problem, the demangler is already a separate DLL with a very simple interface (demangle.dll/demangle64.dll).
#include <cxxabi.h> #include <stdlib.h> extern "C" char *__declspec(dllexport) DemangleCXXName2(const char *pName) { int status = -1; return abi::__cxa_demangle(pName, 0, 0, &status); } extern "C" void __declspec(dllexport) FreeDemangledCXXName(char *pName) { free(pName); }You can build with MinGW using the following command line:
g++.exe demangle.cpp -o demangle.dll -shared -static-libgcc -static-libstdc++
We will update the version shipped with VisualGDB based on the latest MinGW toolchain in the final v6.1 release.
- If (ID = ‘xxx’ and VERSION = ‘yyy’)
