[support]

Sorry about that and thanks for the log. It looks like the pointer size did get queried correctly, so it’s hard to say what is going on.

We have added more logging to this build: VisualGDB-5.5.1.3331.msi

Please try enabling View->Other Windows->VisualGDB Diagnostics Console and reproduce the problem. Then attach the lines starting from “Parsing ‘<expression>'” and we should be able to understand what is going on and provide a hotfix.

[support]

Hi,

This part is only relevant for VS2015+ that supports fast up-to-date check plugins (invoked before showing the “Project XXX is out of date” message). It should not affect any other functionality and can be safely ignored.

[support]

Sorry, the log doesn’t seem to have anything out of the ordinary, so the only other option would be to try various reset/reinstall steps suggested earlier.

You can also try using the /ResetSkipPkgs option, although it may not work either.

[support]

No problem, we have reviewed the related logic and found a possible cause. Please try this build: VisualGDB-5.5.1.3330.msi

If it doesn’t help, please send us a full gdb log and we will do a deeper investigation.

[support]

Sorry, that would be a tricky one to diagnose. Visual Studio uses an opaque cache object to store the menu commands from various extensions, and if it gets corrupt, there is no known way to deterministically repair it.

We could recommend a few workarounds, but none of them is guaranteed to work 100%:

1. Try running devenv.exe /Log and checking the ActivityLog.xml file. If it shows a specific reason why VisualGDB is not loading, it might give some troubleshooting clues.
2. If VisualGDB is just not mentioned in the log file, try creating another temporary user account on that machine and see if VisualGDB menus appear there. If they do, try moving out the Visual Studio’s per-user registry keys and folders (under %LOCALAPPDATA% and %APPDATA%) and restarting it. This will reset all per-user settings and should get VisualGDB to show again.
3. Also reinstalling or repairing VS via Add/Remove programs might help.

[support]

Hi,

Complex projects like Qemu usually handle dependencies different from each other, so VisualGDB doesn’t provide any special interface for managing them. Hence, the easiest way to debug a tool like Qemu would be to use the Quick Debug feature.

Another option would be to run the configure step manually, ensure that the “Make” command succeeds from the command line and then import the project as an external project built with command-line tools. When VisualGDB asks for the build command-line, you can specify the following to trigger an msys-based build with the correct environment:

• Command: <path to mingw>\usr\bin\bash.exe
• Arguments: –login -c “cd <directory> && make”

Debugging normally does not require the special environment, hence using the regular settings to specify the debugged executable should work.

[support]

Hi,

Please try installing any other extension via Tools->Extensions and Updates. This should force Visual Studio to rebuild the menu cache.

If it doesn’t help, please double-check whether VisualGDB commands appear under Tools->Customize.

[support]

Thanks for finding this out. We would normally want to avoid modifying the hidapi source code (as it would involve forking it just for that change), so we have instead updated our OpenOCD to replace the serial number received from the command line with a correctly-cased version once a case-insensitive match is found. Please try this build and let us know if it works: https://sysprogs.com/files/tmp/openocd.exe

[support]

Hi,

The VisualGDB’s linker scripts indeed follow a very basic structure. If you would like to make use of the additional memory definitions, please try downloading the XMC Peripheral Library from Infineon and importing the linker scripts from it.

[support]

Hi,

No problem, we have released an update to the Infineon BSP resolving this issue. Please update it via Tools->Manage VisualGDB Packages.

[support]

BTW, we have just updated our IAR tutorial showing the new out-of-the-box integration. Feel free to use it as a reference while troubleshooting IAR-related issues.

[support]

OK, we have updated our OpenOCD fork to do case-insensitive comparison for CMSIS-DAP serial numbers.

Please feel free to update your copy via Tools->VisualGDB->Manage VisualGDB Packages->Updates and let us know if it resolves the problem.

[support]

Yes, here’s the relevant command line:

cd E:/NCA/Webservice/branches/stability/Services/VisualGDB/Debug/src/comms && c:/SysGCC/raspberry/bin/arm-linux-gnueabihf-g++.exe --sysroot=c:/SysGCC/raspberry/arm-linux-gnueabihf/sysroot -IE:/NCA/Webservice/branches/stability/Services/spdlog -IE:/NCA/Webservice/branches/stability/Services/src/comms/include -IE:/NCA/Webservice/branches/stability/Services/plc/include -IE:/NCA/Webservice/branches/stability/Services/src/plc/include -g -Werror -std=c++14 -o CMakeFiles/NFC-PLC-Comms.dir/src/NFC_comms.cpp.o -c E:/NCA/Webservice/branches/stability/Services/src/comms/src/NFC_comms.cpp

However, it doesn’t seem to mention /usr/local/include at all, so most likely your project somehow overrides or resets the include directory list for the target. As the CMakeLists.txt structure was not created by VisualGDB, it’s hard to suggest a specific spot where it could be happening.

That said, if you have trouble navigating the CMakeLists files of this project, please consider re-creating it from scratch using the VisualGDB GUI for adding targets and setting their properties. This will ensure that all target properties will be stored consistently and won’t conflict with each other.

[support]

Hi,

Normally, the IAR should work out-of-the-box and modifying the Makefile should not be necessary.

Please double-check whether the IAR toolchain appears on the Toolchain Selection page of the VisualGDB Embedded Project wizard:

• When creating a new project from scratch
• When trying to import a project

If the toolchain appears while creating a new project and doesn’t appear while importing it, would you be able to send us the .ewp file so that we could check what is going on?

[support]

Thanks for clarifying this. Indeed, depending on the way the toolchain was built, the touch.exe command might depend on some other DLLs.

That said, if your Makefile track file dependencies properly, you can simply use the “cmd /c echo “//This file was updated” > trigger.h” command and include trigger.h from your main file. This will override the contents  of trigger.h with the “//This file was updated” string, but will be otherwise equivalent to using the touch command. Also please consider setting up a custom VisualGDB shortcut for this operation, so you can conveniently trigger it via the VisualGDB menus when needed.

[Author]

Posts