[support]

Hi,

Sorry, not sure what you meant. If you believe VisualGDB is not working correctly, please provide complete screenshots showing every step of the wizard, and every other step you take (e.g. changed settings), including the final error message you get. Please ensure the screenshots are complete and uncropped. A single error message taken out of context is often not enough to suggest anything meaningful.

[support]

Hi,

No problem, we have reproduced and fixed the issue. Please try this build: VisualGDB-6.0.103.5197.msi

[support]

Hi,

Thanks, looks like the U5 port is using a couple of built-in functions that are not known to Clang and somehow trigger strange behavior.

We have added a workaround on the VisualGDB side. Please try this build: VisualGDB-6.0.103.5197.msi

[support]

Hi,

Sure, it should work just fine. Just make sure you are using the latest VisualGDB 6.0R3 and selecting the ST fork of OpenOCD.

[support]

Hi,

Thanks, we have reproduced and fixed the problem. Please try this build: VisualGDB-6.0.103.5196.msi

[support]

Hi,

You can actually override this by setting the SYSPROGS_TEST_REPORTING_PIPE environment variable to /dev/null. This will suppress the warning and will make the test framework work pretty close to the original unpatched version.

[support]

Hi,

Most likely, you are using incompatible versions of ESP-IDF, ADF and the toolchain. Please refer to this page for more information: https://visualgdb.com/documentation/espidf/#espadf

[support]

Hi,

It should not be an issue anymore. Either way, you can try creating a new C# console application (using .Net framework, not .Net Core) with the following code:

var rg = new Regex(@" \(WSL (\(|\))");
var ifaces = NetworkInterface.GetAllNetworkInterfaces().Where(iface => rg.IsMatch(iface.Name)).ToArray();

Does it find the one-and-only WSL interface?

[support]

Hi,

Sorry, it looks like the SMB connection between the Linux machine and Windows machine fails at some point, but it’s not something VisualGDB can automatically fix.

You can try using the usual white box / black box troubleshooting:

• Capture a WireShark trace of network communication between Linux and Windows and analyze it. It should give a good insight into the cause (some SMB request will be failing with an error), but getting to the bottom of it will be a very tedious task, trying to understand thousands of network packets.
• Alternatively, you can try simplifying the repro. Instead of a build, try reading all sources one-by-one. If it doesn’t trigger anything, do it from multiple threads. Try varying the number of threads, making pauses, etc. If it turns out that some particular pattern triggers the problem (e.g. more than X threads in parallel), you might be able to work around it by tweaking the build process.

[support]

Hi,

Thanks for renewing your license.

The VC++ IntelliSense takes the language standard version from the ClCompile/LanguageStandard element in the .vcxproj file (note the condition attribute). You can try changing it via the VS project properties for the non-VisualGDB project and observe how the value changes (e.g. to stdcpp17).

VisualGDB uses separate language standard settings for C and C++ files (CLanguageStandard/CPPLanguageStandard), so the native VC++ IntelliSense does not pick them up automatically.

You can try manually copying the LanguageStandard element into the VisualGDB’s .vcxproj file (also under ItemDefinitionGroup/ClCompile) and reloading the solution. VisualGDB should ignore it, but the VC++ IntelliSense should pick it up.

 

[support]

Hi,

Thanks for reporting this. We have fixed it in this build: VisualGDB-6.0.103.5194.msi

[support]

Hi,

OK, we have rechecked the test discovery logic for the simulation platform and it should be possible to get multiple test targets working without any modifications on the VisualGDB side.

First of all, please try cloning this example and duplicating the add_bsp_based_executable() statement to add another target with a different name, but same sources. Then build the solution (simulation platform). Test Explorer should now show 2 sets of tests.

To replicate it in your solution, you would need to manually define a couple of cache variables via set(… CACHE INTERNAL “”)

1. For each executable, set <executable name>_TEST_FRAMEWORK_TARGET to the name of the static library target that corresponds to the test framework.
2. For the actual test framework, set <static library name>_TEST_FRAMEWORK_ID to com.sysprogs.unittest.googletest

You can check the variables defined by our example project by viewing the cache-v2-<id>.json file in <project directory>\.visualgdb\VisualGDBCache\EmbeddedSimulationDemo-Debug-Simulation\CodeModelCache. If your project manages to define the same cache variables, VisualGDB should be able to locate and discover all test targets and not just the startup one.

[support]

Hi,

Thanks for confirming this. In general, the VS IntelliSense is not directly controlled by VisualGDB. We can show you where it looks for settings like language standard and how to try manually applying them to a VisualGDB project, however it may still not work if it expects something specific to regular VC++ projects. If you would like to go ahead and try it, we would kindly ask you to renew your support first.

[support]

Hi,

The regular IntelliSense is managed directly by VS and might not support C++17 if you are using an older Visual Studio. Even the latest Visual Studio might not support some variants of GCC extensions.

Does IntelliSense work as expected with similar code on a regular Win32 project (non-VisualGDB based) and the same VS version?

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[Author]

Posts