Forum Replies Created
-
Posts
-
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.
Good to know it works. Generally VisualGDB reconstructs the ESP-IDF project structure from analyzing the build logs, so if you get the “ESP-IDF build log did not report any built executables” error, trying to build the project would either resolve it (it if previously failed due to missing generated files), or point directly at the cause of the problem (i.e. a meaningful error message produced by the ESP-IDF build system).
The USE_FULL_LL_DRIVER is just a regular preprocessor macro, so you can easily set it via the regular build settings as shown below:
Regarding the automatic fix, if anyone could share the exact up-to-date repro steps for the issue and point out which files or flags need to be included, we should be able to add a workaround on our side in 1-2 business days. Otherwise, it will go into a lower priority queue, since it involves issues in 3rd-party components and we currently working on a few improvements to VisualGDB itself (specifically, stable VS2019 support and eliminating delays during VS startup).
No worries. If 2 very similar projects behave differently, it might be caused by an internal exception in VisualGDB while it’s handling a different part of the startup sequence. Please check View->Other Windows->VisualGDB Diagnostics Console for details.
If this doesn’t reveal anything, please try combining different parts of working and broken project (e.g. .vcxproj file from project A with .vgdbsettings file from project B, or <Build> element from project A with the <Debug> element from project B inside the .vgdbsettings file). This should help narrow it down fairly easily.
Hi,
The linkerinputs page indeed uses old screenshots, however it still reflects the structure of the GCC’s linker inputs and does not apply to Keil projects (since the Keil compiler has its own documentation and support, we would advise checking it first).
The errors look like the Keil compiler is missing some target-specific flags. Please try enabling the “generate .bat file” option in the uVision GUI, build the project and check the armcc command lines in the generated bat file (they will refer to reponse files with the actual command line parameters). Then check the command-line options used by VisualGDB by viewing the .gcc.rsp files in the VisualGDB\Debug subdirectory. If you could identify a specific flag that is different between uVision and VisualGDB, please either add it via VS Project Properties -> C/C++ -> Command Line, or let us know and we will see why VisualGDB doesn’t add it automatically.
If you cannot find the difference between the 2 projects, we would need to know the exact steps to reproduce it on our side so that we could check what is going on.
This looks like a known issue. It should not trigger in v5.4R2, however it would be present in some of the daily builds after it. We are currently refactoring the initialization logic of VisualGDB to make different components initialize on-demand and completely eliminate any delays during Visual Studio startups, so some of the daily builds were indeed buggy.
Please try this one, it has the breakpoint problem fixed: VisualGDB-5.4.103.2958.msi
Sorry, we do not support 8051 devices as they do not have a GCC/GDB-based toolchain and are not as popular as ARM-based devices.
Sorry, this doesn’t look like any known issue. If you could provide the exact repro steps for the problem, we should be able to tell what is going on.
