[support]

Hi,

The automatic sysroot synchronization indeed can only download the files from the root of the target filesystem. The easiest way to work around it would be to synchronize the files manually using SmarTTY, or add custom project shortcuts (requires Custom edition or higher) for downloading the arbitrary directories from arbitrary machines into the toolchain’s sysroot. Once defined as a custom shortcut,  you will be able to trigger synchronization via the Project menu.

Regarding the case sensitivity, such files will indeed override each other on the Windows side. You can try enabling the case-sensitive mode for a specific NTFS folder as described here, but this may not be handled correctly by the toolchain or Visual Studio itself. Generally, unless you are building custom kernels, this should not be a problem as this type of file name collisions is rare. If it does interfere with your projects, please consider creating an Advanced CMake-based project configured to directly access the remote filesystem via SSH. This mode will properly handle case-sensitive file names, although you would need a Linux machine to build the code.

[support]

Thanks for the update. Looks like the busybox version on your target is more limited than one we tested.

The problem happens because VisualGDB tries to run the following command line in order to list all files in a certain directory:

find . -maxdepth 1 -print0 | xargs -0 stat -c "StatEntryL:|%N|%Y|%d|%s|%f"

It uses the ‘-0’ option so that xargs won’t get confused if some of the file names have spaces. We have tested this on busybox 1.27.2 and it did work, so if possible, please try updating the busybox version on your target. If this is not possible, please try running ‘xargs –help’ on your target and share the output so that we can try to find a command line that will work on your target.

[support]

Hi,

Please double-check with Espressif (the vendor for ESP-IDF) whether there is an officially supported and stable way to do this. If yes, we will be happy to add a GUI setting for it.

[support]

Hi,

VisualGDB sets the optimization level to “none” for debug builds because this makes it easier to debug the project. Debugging optimized code could be very complicated as the compiler would often reuse common chunks of generated code (complicating stepping) or destroy the values of the variables once they are no longer needed (preventing you from evaluating most of them in the debugger).

If your project only works with some optimization levels, but not with others, it likely contains bugs triggered by a specific memory layout, or runs out of stack/heap space. Either way, we would advise investigating this as it might cause further trouble in production code.

[support]

Hi,

Yes, simply right-click on the project in Solution Explorer, select “Open ESP-IDF terminal here” and VisualGDB will launch the MinGW2 shell where you can run commands like “make monitor”.

If you are looking for something different, please let us know and we will try to provide a better suggestion.

[support]

Thanks for the project files. From a very brief look, it appears you main test project had code coverage disabled on the MSBuild level, so the test container generated by MSBuild (that is essentially a snapshot of MSBuild-level properties necessary for VisualGDB to launch the project outside MSBuild) did not have any coverage-related settings.

After we changed the setting (see below), the container appears OK.

We will run a few more tests on your solution and see if we can improve the usability for this scenario.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Thanks for reporting this. We have added support for detecting busybox and using a different command line in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2792.msi

BTW, installing SysprogsSync to the target should be very straight-forward (see this page). It’s just one C++ file, so you can simply build it with the cross-compiler and deploy it to /usr/bin. That will significantly increase synchronization performance compared to file-by-file mode.

[support]

Hi,

Please try setting the VISUALGDB_VERBOSE_OUTPUT and VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT variables to 1 before running VisualGDB. This should produce a much more detailed error message, that should help us pinpoint the root cause (likely one of the XML files being corrupt).

VisualGDB runs unit tests on the hardware by automatically programming the target with OpenOCD (or J-Link depending on the project configuration), reading structured test reports via semihosting and reporting the results to VS. Normally all you need to do is run VisualGDB.exe /runtests <test container file> on a machine/user account where you would be normally able to debug the project (i.e. that has all the necessary packages installed) and VisualGDB will do everything automatically and will generate a report file (see output from running VisualGDB without arguments for a detailed list of the supported switches).

Let us know if you have any further questions and we will be happy to help.

[support]

Good to know it works.

The ADDITIONAL_MAKE_FILES line in debug.mak and release.mak might get overridden if you edit some of the settings. A safer bet would be to add linux.mak to this variable in the Makefile itself (just before the ADDITIONAL_MAKE_FILES variable gets read).

[support]

Hi,

If you are using MSBuild, please use the regular VS Project Properties (Configuration Properties -> General -> Target Type = Static Library). For Make-based projects, please use the “Makefile Settings” page of VisualGDB Project Properties.

[support]

Thanks, we have received the project. Unfortunately, we could not reproduce any issues – it got loaded correctly immediately:

Please try deleting the ‘VisualGDB’ subdirectory in the solution directory that contains IntelliSense cache (ensure that the CodeDB folder gets deleted), and if it doesn’t help – try opening the project on a different machine, as the problem might be caused by a corrupt VS installation or a conflict with another VS extension. Please also ensure you are using the latest VisualGDB 5.4R2.

Attachments:

You must be logged in to view attached files.

[support]

The options in the VisualGDB Project Properties (except the J-Link executable path that is shared) are actually defined per project/configuration pair, so it’s safe to use the second setting you mentioned.

Please try using the $(ProjectDir) variable to avoid hardcoding absolute paths.

[support]

Thanks for the screenshots and the file, however unfortunately we could not reproduce the problem.

If this is a simple test project anyway, would you be able to send us the entire project (you can use the support form to send the files). If not, please check the Clang IntelliSense Diagnostics Console for error messages or anything suspicious after you save the main source file (and trigger a reparse).

[support]

Thanks for clarifying that you have 2 projects. Most likely the problem is triggered by some combination of settings in those projects (we have previously tried to reproduce it with 1 project only), although it’s hard to pinpoint it from the current screenshots . The test container is missing the <CodeCoverage> element, so that explains why the code coverage it not handled, although this could be triggered by several different options.

Would you be able to reproduce the same problem on 2 freshly created projects, demonstrating the same settings (test frameworks, references between the projects), etc, and attach them here or send them via our support form? This should help us pinpoint and fix this without requesting any more details.

[support]

Hi,

Please try using VisualKernel as shown in this tutorial. It should configure the necessary debug settings automatically.

[Author]

Posts