[support]

Hi,

Please use Test->Run all tests or Test->Debug All Tests (or right-click on individual unit tests in Test Explorer) to run tests. Simply running a test project with F5 will not engage the extra logic for selecting tests and reporting/interpreting test results.

[support]

Hi,

It looks like VisualGDB did not manage to save one project file after modifying it (TC2.jpg). This sometimes happens if the project is not loaded correctly in the Solution Explorer, or if some other bug prevents it from being saved. Could you try locating the project that fails to update (e.g. by checking which of the projects did not get modified)? Does excluding it from solution solve the problem? If yes, could you compare that .vcxproj file with other .vxcproj files to see if some manual modifications could be causing this?

This problem also sometimes happens when you try pressing ‘upgrade’ while VS is still loading the projects, so simply waiting 10-15 seconds before pressing it may help.

With ‘missing toolchain ID’, the logic responsible for fixing it could get interrupted by broken toolchain updating process, so once you resolve problem #1, the problem #2 should get automatically resolved as well.

[support]

Hi,

OK, we have published a detailed tutorial showing how to use VisualGDB with TFS here: https://visualgdb.com/tutorials/ci/tfs/

Please try updating your VisualGDB to the latest v5.3 and follow the tutorial. Please try checking that the %VISUALGDB_DIR% variable is defined correctly in the command prompt window where you launch the build agent (it should not have a trailing ‘\’).

[support]

Hi,

Strange, it looks like a statement that should normally be added to non-MSBuild projects got added to an MSBuild-based one. Could it be that the same project combines both MSBuild and non-MSBuild configurations? Also if you could share the project file with us via support form, or post it here, this would help understand what is going on.

[support]

Hi,

It looks like something inside the logic responsible for finding VS instances hangs. It’s hard to say what would be causing this, so we could only give some generic advice:

• See if msiexec.exe launches any other tools or tries to access some inaccessible paths or registry keys (using Process Monitor).
• Try reinstalling/uninstalling Visual Studio.
• Try completely uninstalling the previous version of VisualGDB and installing the new one. If this doesn’t help, try running the v5.2 installer and check if it hangs the same way.

[support]

Hi,

The new r6 build fixes the FLASH memory type/size settings. Perhaps your device has a smaller FLASH memory than your settings specify?

If not, please try changing any settings on the Debug Settings page of VisualGDB Project Properties and then manually set the ‘PatchBootloader’ field in the .vgdbsettings file to ‘false’. If this solves the problem, please try switching the FLASH mode to DIO and reducing the FLASH size.

[support]

Hi,

ESP32 is generally much less reliable than ARM-based devices, especially if using pre-release version of the IDF, so strange bugs are to be expected and unless you are OK with resolving them, we would recommend staying with a stable ESP-IDF release until v3.0 is officially released as well.

With debugging stops, it could be a known VS limitation. Pressing Shift-F5 before VisualGDB reports that the session has started, would send Visual Studio into a 30-second wait. If this is the case, please try stopping the session by pressing “cancel” in the GDB Session window instead, then VisualGDB will immediately report session termination to VS.

If this does not help, please let us know if stopping the target (Debug->Break All) and then terminating the session works.

[support]

Hi,

No problem, here’s the link: http://sysprogs.com/files/tmp/VisualGDB-5.3.11.1847.msi

[support]

Hi,

Thank you for your input. We do investigate all bug reports submitted to us, however some of them correspond to very specific cases (or simply cannot be reproduced on our side), so we are unable to pinpoint and fix them without further details and follow-ups.

W.r.t. the 10-line bug, according to our records, the support ticket describing it was submitted on 10/09/2017 9:41 am and we sent you a hotfix on 10/10/2017 5:30 pm. We understand that you might have been experiencing the problem for a long time prior to submitting a ticket, however we are not able to resolve rare issues unless they are actually reported via the forum or support form.

Regarding the deletion issue, we have tried reproducing it and measured roughly the same performance using the regular VS IntelliSense and VisualGDB Clang IntelliSense. We have requested further clarifications in this thread and have not heard from you since. Please feel free to post your findings there so that we could continue the investigation.

[support]

Hi,

VisualGDB includes a separate IntelliSense engine optimized for GCC-specific code (like most embedded libraries), so its settings generally differ from the regular C++ settings. That said, VisualGDB detects and imports most common C/C++ language settings from the regular C/C++ pages, so you don’t need to set the same settings twice. If you believe this is not the case for some settings, please let us know and we will investigate.

You can easily combine VisualGDB projects and regular Win32 projects in one solution. If the same file is shared between VisualGDB and a non-VisualGDB project, VisualGDB will rely on Visual Studio to determine the project corresponding to the file. Depending on the VS version and settings, it may treat it as a part of the VisualGDB project or as a part of the regular VC++ project.

If this causes confusion, we would advise temporarily unloading irrelevant project during development so that Visual Studio could uniquely identify the projects for all source files.

[support]

Hi,

IntelliSense should not be related to the fix we added for debug visualizers. Please try double-checking if you can get the same behavior with a minimal “hello, world” project. If yes, please post the code here so that we could check it (we quickly tried it with “std::make_unique<std::string>()->” and it worked as expected).

[support]

Hi,

Thanks for confirming this. The only other advice would be to ask in the clang/llvm mailing lists. This might be a known issue and someone from the clang community might be able to suggest a better workaround.

[support]

Hi,

If you are using a Custom edition or higher, you can create a custom pre-debug action (or a custom shortcut) to transfer the necessary files. Both can be configured via VisualGDB Project Properties; pre-debug actions are always launched before debugging, while custom shortcuts can be launched manually via Project->VisualGDB Custom Shortcuts menu.

Another option would be to simply add “*.xml” to the list of transferred file masks on the first page of VisualGDB Project Properties.

[support]

Hi,

Thanks, looks like the UART baud rate might be set incorrectly. Normally the initial gdb stub message should look like this:

$T05#b9

Please try setting the UART speed explicitly by calling the following function before gdbstub_init():

    UART_SetBaudrate(UART0, 74880);

If this does not help, please check the schematics of your board to see the crystal oscillator frequency. The default UART baud rate would be 115200 * (frequency / 40 MHz). E.g. for 26 MHz it would be 74880 .

[support]

Hi,

The mainstream OpenOCD usually starts supporting STM32 devices a few months after they are released (we rebuild our package from the latest sources regularly).

If you don’t want to wait, please try replacing the OpenOCD binary in %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin with the version from the AC6. Normally no script modification should be necessary, however if it doesn’t help, please try using the script from the AC6 distro as well.

If this does not work, please let us know and we will be happy to help.

[Author]

Posts