Forum Replies Created
-
Posts
-
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.
As mentioned in the previous reply, the “undefined reference” error means that the file providing the definition (not declaration) of a function is not included in the project. Normally, searching the nearby files for the function name should help locate the file defining it.
Please check the contents of the “.\objects\p0top1.__i” file listed in the Keil’s batch file. It is the response file mentioned in our previous reply and it should contain the actual command line arguments for the Keil compiler. Please also double-check that the P0toP1.c file is indeed the one triggering the problem (you can recheck it by compiling just the current file by pressing Ctrl-F7 in Visual Studio).
The “undefined reference” error means that the file providing the definition (not declaration) of a function is not included in the project. Normally, searching the nearby files for the function name should help locate the file defining it.
If you are not sure about the function declarations vs. definitions, please consider reading this tutorial. It explains the differences based on a few specific examples.
The second problem looks like something that was recently fixed on our side. Please try this build: VisualGDB-5.4.103.2978.msi
Just wanted to let you know that we have merged our arduino-builder fork with the upstream repository and updated the binary shipped with VisualGDB.
Please feel free to try this build: VisualGDB-5.4.103.2978.msi
Thanks for sharing this.
We have tested a few scenarios related to IntelliSense in newly added files and have found one potential cause of the problems: if you add a header file to the project and do not include it from any source files, the Clang IntelliSense will try to guess the compiler arguments for that file, that might not always be correct, especially for projects with multiple targets. We have added a special warning for this case and a button that allows rescanning the solution for files that could include the header file without reopening it.
If anyone else encounters issues with header files and Clang IntelliSense, please try this build: VisualGDB-5.4.103.2978.msi
We have also published a tutorial on diagnosing IntelliSense-related problems here: https://visualgdb.com/tutorials/IntelliSense/
We will try to make this process fully automatic in one of the next VisualGDB releases.
No problem. Please follow the instructions described in this thread to disable CodeJumps annotations.
The little green arrow might be something shown by Visual Studio itself. If you could attach a screenshot, we should be able to tell whether it comes from VisualGDB.
Thanks for the update. The break-in dialog does not always indicate a problem. It simply means that the gdb stub (i.e. OpenOCD) is taking some time to communicate to the hardware and wait for it to stop (in the previous version that branch was never taken due to a bug on our side).
The “deprecated” message is related to the internal OpenOCD script names and can be ignored. We will update our interface description files accordingly in one of the next releases of the OpenOCD package.
Indeed, the new build fully enables the on-demand loading, so Visual Studio startup will no longer be slowed down by VisualGDB. It will only initialize itself when running a wizard, clicking on a VisualGDB-related menu command, or opening a VisualGDB-related project.
