[support]

No problem, we will clarify. VisualGDB supports many different project types. Some of them (like MSBuild or Advanced CMake) are recommended for new setups, while others (like Makefile-based) are considered legacy and are only recommended if you need backward compatibility with older VisualGDB versions, or projects that were created earlier.

[support]

No problem. This looks like a legacy VisualGDB project type that is internally implemented as a NMake-based VC++ project. You can try narrowing down the problem by creating a regular VC++ Makefile project via the VC++ project wizard and setting a dummy build command (e.g. “cmd /c echo done“). If it breaks the same way, please try checking with Visual Studio support.

If the VisualGDB-based project behaves differently from the regular NMake project, please try comparing and merging the .vcxproj files. Some element (e.g. PlatformToolset) could be set differently in these 2 projects and could be causing this behavior.

Also, for most of the new project setups we recommend using Advanced CMake projects. They do not require the VC++ project subsystem and often work more reliably.

[support]

Hi,

Thanks for reporting this. We have reproduced and fixed the issue. Please try this build: VisualGDB-5.5.102.3881.msi

[support]

Hi,

As the message suggests, ninja expects to be run as root on Raspberry Pi.

You can configure Raspberry Pi to permit root logins as shown here and then create another SSH connection in the VisualGDB wizard or project properties (root@raspberrypi instead of pi@raspberrypi).

[support]

Thanks for the update. VisualGDB does show a clear message when the trial expires, as long as you do not modify any components or registry keys. Manually editing licensing-related keys will indeed suppress the expiration message, but will still prevent VisualGDB from working.

[support]

Sorry, it looks like some of the files are corrupt on your side. Unfortunately, this is outside of our control and hence we are not able to resolve it from our side.

[support]

Please make sure you use an unmodified VisualGDB installer and do not modify the downloaded packages in any way either. As long as both VisualGDB and the packages are not modified, the installation will work out-of-the-box in both online and offline modes.

[support]

No problem, please try replacing the SysprogsUnitTestInterface.c inside the toolchain with the updated version from the VisualGDB directory. This should fix the setting check.

[support]

Sorry, we could not find any orders associated with this email address. If you have any other information related to your order (e.g. an order number or the license key), you can submit it via the support form and we will link it to your profile.

[support]

Hi,

This looks like an issue specific to the STM32 microcontrollers and not something VisualGDB-specific. Please consider posting STM32-specific questions in the STM32 community instead.

[support]

Hi,

It looks like the target board is missing the ninja tool that is used to check dependencies and rebuild out-of-date files without any extra network delays. You can install ninja by running “sudo apt install ninja” on Raspberry Pi, or by creating another MSBuild-based project targeting that device from scratch, so that VisualGDB could recheck and install the required tools.

[support]

Hi,

Please let us know the email associated with your license key so that we could check your support status.

[support]

No worries, the RAM/ROM sizes should not have any effect on this, most likely the issue is caused by inconsistent modifications to some files.

Please try this build: VisualGDB-5.5.102.3879.msi. It contains a definition for the RL78 toolchain.

If the problem persists, please let us know the stack trace from the “details” view of the exception message box, and also try enabling diagnostic logging via View->Other Windows->VisualGDB Diagnostics Console. It should explain where exactly the problem is triggered.

[support]

Hi,

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

[support]

Thanks for the detailed log files. Unfortunately, it looks like the problem triggers somewhere inside the Visual Studio’s CppClean task and not in any part of VisualGDB, so it’s hard to pinpoint the exact cause of it:

1> Using "CppClean" task from assembly "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.Build.CppTasks.Common.dll".
1> Task "CppClean"
1> Task Parameter:FoldersToClean=pathToProjectRootWin\micro-tools\Hal\VisualGDB\Release\HAL_out;VisualGDB\Release\HAL_obj\
1> Task Parameter:FilesExcludedFromClean=libHAL.Build.CppClean.log
1> Task Parameter:DoDelete=True
1> Task Parameter:FilePatternsToDeleteOnClean=*.o;*.dep;*.tlog;*.rsp;*.bin;*.ihex;*.map;*.S;*.E;*.msbuild-mak;*.alldeps;*.remotedir
1> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppClean.targets(76,5): error : The parameter is incorrect.
1> C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppClean.targets(76,5): error :
1> Output Item(s): DeletedFilesByCppCleanTask=
1> Done executing task "CppClean" -- FAILED.

One thing to try would be to delete the directories shown in FoldersToClean manually and see if it triggers any error (e.g. interference from the antivirus). If it doesn’t help, the only way to narrow it down would be to create another similar project from scratch, ensure that it cleans successfully, and then move the contents of the broken project into it step-by-step:

1. Replace the .vgdbsettings files and ensure that building and cleaning still works.
2. Replace the list of source files (<ItemGroup> nodes in the .vcxproj file) and ensure cleaning still works.
3. Replace the common build settings (<PropertyGroup> nodes) and ensure cleaning and building still works.

If you could pinpoint a specific part of the .vcxproj file that triggers the problem, we should be able to suggest a workaround. Otherwise unfortunately it’s impossible to tell what is causing the issue.

[Author]

Posts