Forum Replies Created
-
Posts
-
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.
No problem, we will help you set it up.
First of all, please note that VisualGDB itself does not support debugging of the C# code (Visual Studio itself might support it if you are running .Net Core), however you should be able to use it for building and debugging of your C++ projects.
The errors you described actually come from a CMake limitation – when targeting Linux (i.e. running on a Linux machine, or using a Linux cross-toolchain), it does not support C# targets as it does not know how to build them using the Linux tools. You could fix this in one of the following ways:
- Instead of defining your C# projects directly, add a custom CMake macro or function to define them. When targeting Windows, this macro should expand to the regular C# project definition. When targeting Linux, it should define a custom target directly invoking the .Net Core compiler, or any other C# compiler you would like to use on Linux. This would be fairly complicated and will involve figuring out the correct flags for the tools and troubleshooting unexpected issues.
- Skip C# targets when targeting Linux. Simply wrap their definitions with an if() statement, or use a custom macro to ensure they will not be created when targeting Linux.
We would advise starting with the second approach (conditioning out the C# targets for Linux builds). This will quickly get to the point where you could build/debug the C++ targets with VisualGDB. Then you could add C# projects to your solution using the approach shown below:
- Add a macro to your CMake scripts that controls whether it should process C++ targets, C# targets, or both (e.g. TARGET_TYPES=CPP/CS/ALL).
- Import the project into VisualGDB by specifying -DTARGET_TYPES=CPP. This will not trigger any errors as the C# targets will be ignored. From the Visual Studio’s point of view, you will have one VisualGDB-provided project (.vgdbcmake extension) containing all C++ Linux targets.
- Manually run CMake with -DTARGET_TYPES=CS targeting Windows. This will generate a regular Windows solution with only C# targets.
- Add the .vgdbcmake project created at step 2 to the solution created at step 3. From the Visual Studio’s point of view, there will be a single solution with multiple C# projects and one VisualGDB project. VisualGDB will simply ignore the C# projects.
- If you are using .Net core, you can try fine-tuning the generated C# projects to build and run on Linux using the regular VS tools. This will not affect VisualGDB, since those projects will be separated from its CMake-based project, so you will be still able to use VisualGDB for the C++ projects.
Hope this explains. Let us know if you have further questions.
We could also do the whole setup for you (including the C# part, researching supported .Net core configurations and getting them to work) as a part of our consulting services. Feel free to contact our sales with more details if you would like a quote.
Please note that we are not able to guarantee that every 3rd-party project imported into VisualGDB will be free or defects and will build without errors, as we do not control the contents of the 3rd-party projects. The Keil project might be generated differently and would hence include the necessary files.
Based on the screenshots you posted, the project does not build because it does not include the definitions for some of the functions it references. As we have suggested before, please search the nearby source files for the definitions of those functions and try adding them to the project.
We will try to add out-of-the-box support for LL projects in one of the next updates to our STM32 BSP (that will include a separate embedded framework and some project examples). Until then, VisualGDB will treat those projects as regular imported projects and hence will expect that they include all the necessary files.
