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

[support]

No problem,

It looks like the IAR for RL78 reports its version slightly differently from IAR for ARM. You can work around it by changing IARToolProductVersion element in the %VISUALGDB_DIR%\Rules\RegularExpressions.xml file. The version below should cover both variants:

IAR (.* Compiler|ELF Linker) (V[^ /]+).* for.*

Then simply restart Visual Studio and VisualGDB should pick up the new regex.

[support]

This is on our radar and will be addressed during the next redesign of the IntelliSense popups. However, it’s hard to give any estimates yet.

[support]

Hi,

Indeed, as the overwhelming majority of devices targeted by our users are ARM-based, VisualGDB was only tested with IAR for ARM. That said, we will be happy to extend this to Renesas targets if you could run a few tests on your side.

Please try searching for IAR in the <VisualGDB Directory>\KnownToolchains.xml file. You will locate a ToolchainLoader element that specifies the exact registry key where VisualGDB searches for the IAR toolchain, and also the names of the compiler/linker and predefined include directories.

You can then copy the <ToolchainLoader> element into another instance and change its contents to match your Renesas toolchain. Then simply restart Visual Studio, or reopen Tools->VisualGDB->Manage VisualGDB Packages, and VisualGDB will detect the new compiler.

We can also do the necessary research and testing on our side, however as the Renesas devices are much more rarely used compared to ARM targets, we would have to charge a customization fee for it (the fee would be credited towards future VisualGDB license purchases).

[support]

This looks like a different popup from the one mentioned in the original thread. Either way, we have added a Tools->Options->Text Editor->C/C++(VisualGDB)->Other->Disable Quick Info setting that allows disabling generic Quick Info popups. Please try this build: VisualGDB-5.5.102.3872.msi

[support]

There are no special steps required on the VisualGDB side to handle included Makefiles. We would advise the following steps to get it working:

1. Make sure you can build the original Makefile outside VisualGDB by launching GNU Make manually as described here.
2. Restructure the Makefile according to your requirements and make sure it still builds. Please note that we are not able to provide any help on this step.
3. If the restructured Makefile works outside VisualGDB, but doesn’t work with VisualGDB, we can help you configure VisualGDB to replicate the stand-alone build results.

[support]

Please refer to our Makefile documentation. It explains this topic in detail.

[support]

Please note that we are not able to provide any help with learning the GNU Make syntax, or other low-level tools. Our support is strictly limited to issues in VisualGDB itself. If you prefer a solution that works out-of-the-box, please consider switching to MSBuild or CMake that are specifically designed to handle this better.

[support]

Thanks for your clarification. Indeed, due to a bug in VisualGDB, excluding a file from mbed-os itself would create a .mbedignore file in the root folder, rather than in the folder containing the excluded file.

We have fixed this behavior in the following build: VisualGDB-5.5.102.3871.msi

That said, we do not advise modifying the contents of the mbed repository itself, as any changes you make will be discarded next time you check out the repository. A better way to customize the mbed port would be to create a custom target as shown in this tutorial.

[Author]

Posts