Forum Replies Created
-
Posts
-
Hi,
Based on what we tested, CoPilot works just fine with the Clang IntelliSense engine. It shows a different language type – C/C++ (VisualGDB) instead of just C/C++, but otherwise works the same:
Also it appears to only use the current source file contents for figuring out the completion. You can try creating a new Win32 Console Application, adding the ESP32 source file there, and it will generate the same suggestions regardless of the unresolved headers and other errors. Note that the suggestions are very sensitive to the exact location in the file – generating a body for the same function defined at the beginning, end, or somewhere in the middle yielded completely different results in our tests.
As for why the original C/C++ engine is disabled, it only works with the project types managed by Visual Studio itself (i.e. native VC++). ESP32 projects are managed by VisualGDB – they don’t use the .vcxproj files and instead dynamically show the exact project structure reported by the ESP-IDF build tools. Regular Visual Studio IntelliSense doesn’t know how to work with such dynamic projects, hence we only allow selecting it for the vcxproj-based projects where it can work.
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
Hi,
This is a known issue between GCC and GNU Make. Some GCC variants produce the dependency files with “c\:\xxx\yyy” path syntax that breaks GNU Make when it tries to recompute dependencies (hence it only happens on the second build).
The workaround is very easy – simply use CMake with Ninja or MSBuild instead, and it will work just fine.
Sorry, there is no quick fix. If you would like to port a CMake-based project to run outside VisualGDB, you will have to learn CMake. If you do not wish to do it, just keep using VisualGDB so that it will handle it for you 🙂
This means that at some point some settings in the project were changed to hardcode the toolchain paths, and regenerating the MCU files reset those settings. Without knowing what exact settings were changed, it is not viable to suggest anything meaningful.
Hi,
The embedded unit test projects are completely separate from other projects. So just including a header file from a different project will not work in most cases. You would need to also have the correct preprocessor macros, include paths, sources, libraries and other relevant settings.
It is not specific to VisualGDB or unit tests – a good starting point would be to create a new embedded application (non-test) from scratch, move the relevant sources there and fix the build errors. Once you get it working, the same steps will work for a unit test project.
Hi,
The easiest way to get it working would be to use exactly the same CMake command line that is used by VisualGDB. You can export it into a batch file (together with the relevant environment) as shown here.
Hi,
Different GCC versions use slightly different optimization logic, so it’s fairly common for a GCC update to trigger previously dormant bugs in the code.
You can try using the new Live Tracing functionality in VisualGDB 6.0 – it can record various function calls on both old and new versions of the firmware into trace files, where you can compare them side-by-side. It won’t directly show the root cause, but it will point to the moment in time when the behavior starts being different.
Hi,
Please let us know the email address associated with your license key so that we could check your support status.
Hi,
All we can see from this error message is that a legacy project (non-MSBuild and non-Advanced-CMake) did not build.
Normally, the errors window or the build log should contain other error messages that should explain what is going on.
Hi,
In our environment, the Raspberry Pi just automatically picked up the date via NTP, so no adjustment was necessary.
If the time sync doesn’t work for you, we would advise investigating and fixing it first. Changing target system time during builds could cause much more problems than it would solve, so we would not advise doing that.
Hi,
If it is a generic Eclipse project (not STM32CubeIDE), VisualGDB won’t be able to import it automatically. Instead, we would advise using the generic import mode of the Embedded Project Wizard to pull all the project sources into a new Visual Studio project. Then, you would need to manually transfer the build settings (list of include directories, preprocessor macros, and device-specific flags).
When importing the project, you can select “specify flags manually” on the MCU selection page (see this tutorial) and later use the first page of VisualGDB Project Properties to specify the device-specific settings. If you use Advanced CMake, you can later export the custom BSP into a reusable package and use it to create new projects easier.
With J-Link, VisualGDB caches the device list in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.segger-dmsp\DeviceList.txt file. You can either delete it to have VisualGDB re-query the device list, or just patch it manually. You can also bypass it completely and edit the J-Link command line manually via the Advanced view in the VisualGDB Settings.
Hi,
Please try updating to the latest VisualGDB 6.0 Beta 2. If the problem persists, please let us know.
Hi,
VisualGDB supports 2 types of custom build steps:
- First of all, you can add custom build steps by editing the build files of the underlying build system (e.g. Makefiles for GNU Make or CMakeLists.txt for CMake). The exact way to do it depends on the underlying build system (Make, CMake, MSBuild, Arduino, etc).
- You can also use the VisualGDB GUI to add custom pre-build/post-build actions. I.e. VisualGDB will execute arbitrary command lines, transfer files, etc. before or after build. These are defined globally (not per-file) and can be configured via VisualGDB Project Properties -> Custom Build Steps. This feature requires the Custom edition or higher, so if you are using a lower edition, you can upgrade it here.
Hi,
Such behavior is usually configured via the sdkconfig parameters. VisualGDB provides a GUI for editing them on the first page of VisualGDB Project Properties, although the exact settings are defined by the ESP-IDF and do not come from VisualGDB.
If you need help locating a specific sdkconfig setting, feel free to ask on the Espressif forums. If you can confirm that the setting works when edited manually but is not working with the VisualGDB GUI, feel free to let us know and we will investigate.
