Forum Replies Created
-
Posts
-
Based on the output log from your first message in the thread, the project fails to build. Hence, the problem is likely not related to IntelliSense at all. Please double-check your code and your settings and ensure the project can be built successfully. If the IntelliSense errors are still shown even after the projects builds successfully, please try reopening the solution so that VisualGDB resets the temporary caches.
Thanks for the update. The easiest way to change the project to Make would be to re-import it via the VisualGDB IDF Project Wizard as a Make project.
However, this will only work if your project directory has the build scripts for GNU Make (e.g. project.mk). If not, please try creating a new project and adding the source files to it via Add->Existing Items so that VisualGDB automatically updates the build scripts.
Sorry about that. We have tried reproducing this, however could not get it to crash (please the attached screenshot and let us know if you spot some critical differences from your setup).
We will also try to suggest a few things to try that might help, but that’s a fairly wild guess:
- First of all, please update to VisualGDB 5.4R3. It uses a different initialization mechanism that might no longer trigger the bug.
- Please try disabling Tools->Options->VisualGDB->General->Debug->Hook ‘Start Debugging (F5)’. This is not needed for advanced CMake projects and is one of the few parts of VisualGDB that is using native code. You will need to restart VS after that.
- Please try completely uninstalling Visual Assist, not just disabling it.
- Please try creating a CMake-based Windows project instead of the Linux one. If it helps, try creating a Windows project and store the sources on the Windows side. The ssh:// paths used by VisualGDB for projects with direct file access might confuse some C#-related logic.
Also please try attaching to the crashing VS using both native and managed debug engines and try to get the full (native + managed) stack trace of the crash. You will need to load the symbols for native DLLs by right-clicking at them in Call Stack in order to get a meaningful trace. Feel free to post it here even if it doesn’t contain any VisualGDB frames and we might be able to suggest something.
Finally, as we could not reproduce it on our side, completely resetting your VS environment (i.e. removing all plugins, %LOCALAPPDATA% folders, etc) might solve this completely. It could be faster than trying to pinpoint the problem (you can quickly check it by installing VisualGDB on another machine).
First of all, please note that we don’t advise trying pre-release builds of ESP-IDF unless you are prepared to do non-trivial troubleshooting, as they are often unreliable and might not be backward compatible.
We normally test VisualGDB with stable IDF releases only, as the internal structure of the pre-release IDF branches changes way too often to be reasonably supported.
That said, we have rechecked the current pre-release v3.3 branch and updated VisualGDB to accommodate the changes introduced in it. Please try this build [VisualGDB-5.4.103.3003.msi].
Also if you encounter problems with CMake projects with this IDF version, please try applying the fix from the github issue we created.
Hi,
Most likely the new variable gets optimized away or placed into a different section. Please try following our linker script tutorial to familiarize yourself with customizing the linker-related settings and techniques used to troubleshoot them.
The “loading” element is shown when the component was just added and ESP-IDF is still trying to update the build files. If it disappears afterwards, the component’s makefiles might be incompatible with the ESP-IDF version you are using. Please try building the project and check that the Arduino component does actually get built and your project is able to call functions from it.
If yes, please share your VisualGDBCache\<Project name>-Debug-VisualGDB\BuildCommandLines.txt file. If the project doesn’t build, the issue might be on the ESP-IDF level and the Espressif support might be able to provide some clues.
Edit: if you are using a pre-release ESP-IDF 3.3 branch, VisualGDB will indeed not be able to locate the components due to changes in the internal ESP-IDF structure. We have added support for it in this build: VisualGDB-5.4.103.3003.msi
The issue with the VC project looks like the RTE_Components.h file got included in the project twice. We have rechecked the scenario you described, however it did not trigger on our side, so it could have been caused by some changes you previously made to the project file. Either way, removing the second reference to the header file from the .vcxproj file should get it back to work.
The behavior with the project importer is a known limitation – as of March 2019, the Keil project importer can recognize files, preprocessor macros and include directories, but not specific Keil frameworks. As a workaround, please specify them manually after you import the project.
Regarding the build issues from the beginning of the thread, please carefully follow the instructions we posted earlier and you should be able to narrow the issue down to a specific flag that is different between the working and non-working project.
Thanks for your suggestions. The new mbed project subsystem is relatively new and is indeed very basic, compared to the regular embedded workflow. We added it in order to support the latest mbed releases and libraries without needing to convert them into MSBuild, that was error-prone due to the large amount of files, custom steps and board-specific hooks.
We do have plans of making it more usable and appreciate your feedback. We will try to add a graphical editor for common build flags in one of the next preview builds after the upcoming v5.4R3 update next week.
We have rechecked the Embedded Memory Explorer, but could not reproduce any problems. If you could share more details or attach a screenshot, we should be able to suggest how to fix the issue you encountered.
Regarding the build profiles, VisualGDB already supports separate debug and release configurations for mbed projects, automatically applying the debug-only build configuration file for the debug configuration. Are you looking for something different (e.g. multiple debug/release configurations for the same target)?
The __cplusplus version is actually queried directly from g++, hence if you edit the mbed configuration files to add those flags to g++ and reload the project (delete the Build and VisualGDBCache directories if simple reloading doesn’t work), it should get the correct values. If it doesn’t happen, please check the command lines in the VisualGDBCache\<…>\CodeSenseDir\MbedCommandLines.txt file. Do they contain the correct -std setting?
You could try using our latest daily build [VisualGDB-5.4.103.2978.msi]
If it doesn’t help, please refer to the previous thread you created regarding IntelliSense issues: https://sysprogs.com/w/forums/topic/dear-developers-please-add-this-major-functionality/
Please refer to the previous thread you created regarding this issue: https://sysprogs.com/w/forums/topic/dear-developers-please-add-this-major-functionality/
Yes, the .vgdbcmake file is actually a fairly lightweight XML file that summarizes the parameters of your CMake build (source directory, build machine, toolchain, extra arguments, etc). It does not store any cached information queried from CMake, hence you can simply create it once via the Import mode in the wizard and then use the file as a template in your generator script (you may want to replace the project GUID each time if you envision including multiple .vgdbcmake projects in the same solution). Even if your project structure changes considerably, the same .vgdbcmake file will still work (and will show the new project structure), as long as the root directory and CMake invocation flags are still relevant.
Hi,
This looks like an issue if the ESP-IDF itself. Please double-check with Espressif whether there is a fix for this.
Sorry, we are not able to review specific projects for errors as a part of our regular product support, however we are happy to share detailed instructions on diagnosing this so that you could narrow it down on your side.
Please try reducing the problem to a specific source file. You can do this by trying to build each of the files in the project one-by-one via Ctrl-F7, or by removing files form the project one-by-one and then building it again.
Once you get to a specific source file, please try running the following command from your project’s directory:
C:\Keil_v5\ARM\ARMCC\Bin\ArmCC --Via VisualGDB\Debug\<file>.gcc.rsp
This should get the same build errors as you are getting in Visual Studio.
Then compare the .rsp file used in that command line with the .i file from Keil, try adding or removing options that are different and re-running the compilation from command line to see whether this fixes the problem. Once you narrow it down to a specific option, we can help you find the VisualGDB setting that controls it.
This could be a bug, or a limitation of a specific framework (e.g. ESP-IDF and Arduino projects only support 1 Debug and 1 Release configuration). If you could attach a screenshot showing the related windows (or send it to our support email if you don’t want to share it), we should be able to tell what exactly is going on and how to work around it.
