[support]

Hi,

Our clang-format-based formatter is indeed based on an older version of Clang (6.0). All options supported by this version should work out-of-the-box. We will update it to use a newer Clang version in the next major VisualGDB release, so the newly added options will work as well.

[support]

Hi,

VisualGDB inherits the regular Visual Studio experience when it comes to libraries:

• You can use the Add->Existing Item command in Solution Explorer to add existing files (including .a libraries) to a project.
• You can use the VS Project Properties -> C/C++ -> Preprocessor -> Include Directories to specify directories with header files.

[support]

Hi,

Thanks for the suggestion. We will consider it in the future, however as the Kendryte devices are very niche, we will likely not be able to do it in the near future.

[support]

Hi,

No worries. Please try calling ReportTicksPerSecond() from your code (it is defined in SysprogsProfiler.h) each time after the system clock frequency is changed. This will have the same effect as setting it manually.

[support]

No worries and thanks very much for the detailed repro instructions.

The problem happened because the part of VisualGDB that determines whether a project contains unit tests without fully loading it (i.e. without opening it in VS or using test containers produced by VS) only scans the main CMakeLists.txt file.

We have updated it to only check the find_test_framework() statement, although it still needs to be present in the main CMakeLists.txt file. Please try this build: VisualGDB-5.5.104.3931.msi

If you want to support a more complex project structure, please consider using the test container files instead. These files (*.vgdbtestcontainer) are generated by VisualGDB when using the Visual Studio’s test explorer, and contain detailed snapshots of various target properties reported by CMake. You can pass a .vgdbtestcontainer file to VisualGDB.exe instead of the .vgdbcmake file, so that VisualGDB won’t need to reconstruct anything by parsing the CMakeLists.txt files. Test container files include the target path, so no /targetpath switch is needed when using them.

[support]

Thanks, we have retested it and indeed the problem is still there (it just doesn’t trigger when VS itself is being debugged). We have posted an update on the Visual Studio bug report and will await a reply from Microsoft. Feel free to post a comment there if the problem affects you as well.

[support]

Hi,

Simply saving all files should do the trick. VisualGDB will automatically update the function index then (you can check View->Clang IntelliSense Status to make sure the updating takes place) .

[support]

Hi,

The “disable optimization” option in VisualGDB simply replaces the optimization flags such as “-O2” with “-O0” when passed to gcc. This works for most libraries and platforms, however, if the library you are trying to build specifically relies on optimization, it may indeed break the build.

As the library does not come from us, we will not be able to help troubleshoot it, so our best advice would be to check the entire build output from the VisualGDB Build window for anything suspicious, and try editing the library to work around the issues raised by disabling optimization.

[support]

Hi,

Please note that our technical support only covers issues in VisualGDB itself. We are not able to help fix errors in specific projects, port libraries, or offer help with freelancing projects without directly billing for the time required to do it.

[support]

Hi,

This looks like a bug in Visual Studio itself. Based on the latest feedback we got from Microsoft, it was triggered by an unexpected combination of flags returned by our debug engine, however from a quick test on VS 16.8.2, it appears to be resolved on the VS side.

Please try updating your Visual Studio to the latest version. If the problem persists, we will try updating VisualGDB to emulate the fields VS would normally expect.

[support]

Thanks, we have located the difference. We have indeed changed the Arduino reset logic to match the Arduino IDE more closely, as another user reported problems with Arduino Nano.

As we do not have the hardware to recheck it on our side, please try downloading and running the attached test project. Does it reset the board properly into the bootloader (with a different COM port)? If not, does removing everything between port.Open() and port.Close() result in a reset?

Attachments:

You must be logged in to view attached files.

[support]

Trying different things at the same time almost always results in strange behavior, and it’s hard to say which of the multiple changed things caused it.

We can gladly investigate it further if you could gather the output from VisualGDB Diagnostics Console in v5.4 vs v5.5 using the same COM port. This will show what has changed and will help us pinpoint the cause.

[support]

Based on the logs you provided, VisualGDB and the Arduino tools use different COM ports (your latest log mentions COM4, VisualGDB log mentions COM6). Please double-check that you specify the same COM port in VisualGDB Project Properties as you use in the Arduino IDE.

[support]

Hi,

No problem. Please try this build: VisualGDB-5.5.104.3927.msi

It uses invariant culture for formatting of timestamps in the .trx files and also updates the BSP files after running VisualGDB.exe /pkgmgr. If the problem with the .trx files persists, please try editing a faulty file manually until it is accepted by your source control system, and then attach both files in a .zip archive (sorry, due to the limitations of our forum engine, it requires a whitelist of supported attachment extensions).

We have tried reproducing the problem with tests in subdirectories, however it worked as expected. Can you confirm that you are specifying the correct .vgdbtestcontainer file when running VisualGDB.exe /listtests? The container file should explicitly mention the target in the Target element. Also if you could create a very basic project, archive it to a zip file (including the .vgdbtestcontainer file) and attach it here along with the exact repro command line and output from VisualGDB.exe, we should be able to fix it promptly.

 

[support]

Hi,

It looks like your Arduino core requires an external reset sequence. I.e. it will pulse the DTR signal on COM6, but will then expect the actual programming port to appear as another COM port. VisualGDB determines this by analyzing the Arduino core parameters and might determine some  settings incorrectly for your board.

Please try double-checking what happens if you program the board with the Arduino IDE. Does it mention COM6 in the logs? Does another COM port temporarily appear in Device Manager during the programming? Are there any command lines for any programming-related tools shown in the Arduino IDE log?

[Author]

Posts