Eclipse Plugin: Indexer Fails on Change of Run/Debug Configuration. Requires Eclipse Restart ESP32-C3 (IDFGH-5458) (IEP-479) #309
Comments
github-actions
bot
changed the title
github-actions
bot
changed the title
|
Hi @BrianAtDocumentedDesigns Thanks for reporting and will verify with the esp32c3 board. "Include Paths" concept is a little different with the Eclipse CMake projects, where the indexer looks at the "compile_commands.json" file generated by CMake build to resolve the include paths. |
|
An immediate workaround could be - delete the "build" folder from the project and build an entire project again and that should resolve the errors. let me know how it goes. |
|
Thanks. Well that does get rid of the unresolved includes but, predictably given the state of ESP32 development tools the debugger immediately shuts down after programming the device, or, if you don't program the device, it goes off into the weeds. |
|
Hi @BrianAtDocumentedDesigns Could you share a screencast/logs for the debugger problem you're referring to?
This issue we could able to reproduce will fix in the next release. |
|
To get started I am using the development branch of ESP-IDF because the released ones do not support ESP32-C3. As explained below I am using a June version of OpenOCD. I am using Eclipse CDT 2021-03 because the ESP32 plug in does not appear to work with 2021-06 (this took me a long time to figure out). There was a bug in OpenOCD whereby it would not program an ESP32-C3 (despite the documentation saying otherwise). This bug was fixed and closed however the corrected OpenOCD binary is not included with Windows ESP-IDF. I cannot build OpenOCD following the directions in the documentation. I raised a bug about that. Alexey was kind enough to send me a build (see espressif/openocd-esp32#162 (comment)). I do not understand cmake enough to attempt to fix the OpenOCD build problem (as you can imagine, since I have spend weeks trying to debug blink I am a little frustrated). If I run debug this which config options actual executable commands It appears to program the device then stop so I can't debug. Open On-Chip Debugger v0.10.0-esp32-20210401-51-g84ee1302 (2021-06-28-14:17) If I run with config options I get or I get Open On-Chip Debugger v0.10.0-esp32-20210401-51-g84ee1302 (2021-06-28-14:17) Info : [0] Found 8 triggers I do not hit the break point set at app_main() I have 2 threads running, however. I have been able to run debug (single step, etc) blink with the old version of OpenOCD but then I had to program with the run config and had all sorts of issues with undefined symbols. I am more than happy to provide you with whatever information, tests, etc, you wish. Thanks for your help with this. Brian |
|
Thanks @BrianAtDocumentedDesigns for providing the log. Let us look into this. |
|
My pleasure. Anything I can do to help or test. One thing with Eclipse is that there is an infinite assortment of options and settings. If you just want to use to IDE, which is my case, you can try as many permutations as you want and still not be sure if there isn't a box or something that isn't checked/unchecked. That's why something like a properly configured default for ESP32-C3 is so important. By the way, the "unresolved includes/cmake" problem is a common one with Eclipse so thanks for pointing to a fix. I am going to post to the ESP32 forum to bring it to people's attention. |
Any specific issue you were facing on this so that we could fix, we have released eclipse plugin 2.1.2 recently to support eclipse 2021-06 version https://github.com/espressif/idf-eclipse-plugin/releases/tag/v2.1.2 |
|
The updated plug does allow me to install 2021-06 and it seems to work. Unfortunately I still cannot get debugging to work though I will continue to experiment. Given that the documentation for the plugin and on the Espressif website are almost entirely about ESP32 and not ESP32-C3, it might be helpful if there was a debug configuration example provided for blink which is known to work on ESP32-C3 using built in USB JTAG |
|
Update. It turns out that I had set sdkconfig ESP System Settings->Channel for console output->USB serial/JTAG So I would be able to trace. I would not hit a breakpoint unless I had a terminal window open. Setting sdkconfig ESP System Settings->Channel for console output->none gets around this problem. So if you want to use the console output you have to open a terminal window. Moreover, I discovered that unless Debug Configuration Main Tab Build Configuration is set to Use Active, the system builds for ESP32 instead of ESP32-C3. The Debugger Tab settings I used are Config Options Actual Executable Note that this will only work if openocd is the June version, not the version distributed with the master branch or release versions of ESP-IDF. Note further that none of this is consistent with the documentation here https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/jtag-debugging/using-debugger.html#jtag-debugging-using-debugger-eclipse |
This command is for flashing only. In order to debug after flashing, Eclipse needs to run OpenOCD with the following args @BrianAtDocumentedDesigns Do I understand correctly that you are able to debug with the version of OpenOCD I provided to you? I double-checked it on my side and it works. But I tested it from the console, not from Eclipse. |
|
Alexey I did but it is complicated. It's complicated. There were multiple issues: under Eclipse if you programmed using the Run profile when you switched to the Debug profile Eclipse would behave as though it could not discover includes (and all the things defined therein). The Eclipse plugin would also populate an incorrect debug profile. In addition, the documentation for setting up OpenOCD and Eclipse for Debugging ESP32-C3 were uniformly wrong. Finally, for reasons not clear, Eclipse would decide it no longer knew you were working with a C3 when you switched to Debug. As such it would refuse to compile. I was able to use the version of OpenOCD you sent me to program the device but I could not get a debug session going. Thanks to help from @kolipakakondal I was able to reduce the number of Eclipse related errors. Finally, as described above, I was able to figure out the correct permutations for Eclipse, OpenOCD, and sdkconfig ESP System Settings->Channel for console output and got debugging with ESP32-C3 built in JTAG working on Eclipse. I had some work to take care of so I am not confident I can do so reliably. I will spend a few days trying various examples to see. I would recommend that you distribute the version of OpenOCD you sent me with ESP-IDF master otherwise anybody trying to get ESP32-C3 working will be very frustrated. I know there was an explanation of how to compile it but I do not understand the explanation. What I can say is that, in general with the ESP32-C3, the documentation bears almost no relation to what you have to do (including building OpenOCD on Windows), but also with respect to the Eclipse plugin, debugging, and so on. This is actually worse than not being documented because the user assumes the documentation is correct and therefore something not working is either their fault or a hardware issue. |
|
New Problem: Building in Debug Config fails After success debugging I closed and re-opened Eclipse. Now I fail with -- Checking Python dependencies... If I switch to the default Run config (i.e. blink) it compiles fine. I do not understand why it can find python with the Run configuration and not the Debug configuration. Since I need the debug configuration to debug (otherwise I get unresolved includes) this is important. JTAG works, but much of the utility associated with the indexer is lost. |
|
Update Potentially significantly, the "look" of the tool bars (upper left) are different. Working Not working |
|
If I close Eclipse then reopen it with the Debug profile selected (not sure if that is important) the problem arises
|
|
v2.2.0 has a fix for this. Please check https://github.com/espressif/idf-eclipse-plugin/releases/tag/v2.2.0 |
|
Seems to work on first tests. I'll update you if there are problems by creating new issues. |
|
Still works great. Thanks for reporting and solving it! |
|
I am using Eclipse Version: 2021-12 (4.22.0) and IDF Eclipse Plugin Version: 2.4.2.202203081345. This problem still exists. This thing seems to have a mind of its own. For a while, I was getting few to no indexer errors. But the errors came back and I'm getting a huge number of them and I can't get rid of them no matter what I do. I think this issue should be re-opened. |
|
I can remember that it was relevant which Launch configuration one selects in the top bar. (And a restart and build sometimes still was necessary to make the issues dissapear. Perhaps you try that again to see if it that helps. |
|
@TobiasBoeschMiele thanks for the response. My launch configuration is set to my project name. It always has been. And recently the indexer was giving me very few "false errors" (one or two - which oddly seemed to vary occasionally). Currently I'm getting dozens of errors and I had not changed my launch configuration. These errors are not only for external symbols but also, in some cases, my own local project includes, methods, and variables. There are two choices "ProjectName" and "ProjectName Configuration". I currently (and have always) had it set to "ProjectName". I've just checked the settings and don't see anything that looks amiss. But there are so many different settings under each of these choices, I am not sure what I am looking for to fix to make the indexer happy. |
This has also been posted here https://www.eclipse.org/forums/index.php/m/1842646/#msg_1842646 but they suggest I post here as well.
Environment
Windows 10 Eclipse 2021-03. ESP-IDF current master branch (required because released ESP-IDF is not compatible with ESP32-C3)
Development Kit: ESP32-C3 mini devkit.
Kit version : [v1|v2|v3|v4] I do not know
Module or chip used: ESP32-C3 v3
IDF version : v4.4-dev-1594-g1d7068e4b (have to use development branch to work with ESP32-C3)
Build System: Eclipse
Compiler version : riscv32-esp-elf-gcc-8.4.0.exe (crosstool-NG 1.24.0.123_64eb9ff) 8.4.0
Operating System: Windows 10
(Windows only) environment type: [MSYS2 mingw32|ESP Command Prompt|Plain Command Prompt|PowerShell].
?
Using an IDE?: Yes. Eclipse 2021-03 (2021-06 is not compatible with the ESP-32 plugin)
Power Supply: USB
Problem Description
I am using Eclipse CDT 03-2021 with the ESP-IDF Plugin. The plugin does not seem compatible with 06-2021 but the described behaviour is the same. Switching from run to debug configuration or vice-verse results in unresolved includes even though it will build with no errors, suggesting the indexer is not in synch with the source. Reindexing, "clean", etc., does not help. Usually a change in configuration immediately results in index issues but if it does not a re-index or build all always does. This seems to be a common problem.
Expected Behavior
Indexer should always work. Restart of Eclipse should not be required.
Actual Behavior
Switching run/debug configuration borks indexer as described
Steps to reproduce
Start a project (i.e. blink) and create a run and debug configuration for ESP32-C3 (note the default debug configuration does not set up properly for ESP32-C3:
===================
Config options
-s ${openocd_path}/share/openocd/scripts -f board/esp32c3-builtin.cfg
Actual Executable
(path to) \riscv32-esp-elf-gdb.exe
GDB Client Setup/Other Commands add
set arch riscv:rv32
Now, switching from run to debug configuration or vice-versa results in unresolved includes even though it will build with no errors, suggesting the indexer is not in synch with the source. Reindexing, "clean", etc., does not help. Usually a change in configuration immediately results in index issues but if it does not a re-index or build all always does.
Switching back does not fix the indexer. I.e. if you start Eclipse with the run config, switch to debug, then back to run the indexer still fails.
If debug works and I change to run, I get the same problem. I have to switch configurations because of an unfixed bug in OpenOCD-ESP. Because of the indexer issue I have to
Below is a summary of the log files of a failing and working index
Note that the working index has an Include Search Path (option -I). I cannot find where to set the Include Search Path option for the indexer. In prior (non-ESP-32) projects when I had unresolved includes (i.e. compile failures) there was an option for "Include Paths" but that is not present in the project or window properties, likely because this is a cmake project.
Fails
Project: SoftAP1
File: file:/C:/Users/bjpic/eclipse-windows/SoftAP1/main/softap_example_main.c
Language: GNU C
Index Version: 219.0
Build Configuration: Configuration
Context: file:/C:/Users/bjpic/eclipse-windows/SoftAP1/main/softap_example_main.c
C, {}
Versions in Index: 1
C: {}; 4 macros, 10 includes, 46 names;
Macro definitions (from language + headers in index):
Works
Project: SoftAP1
File: file:/C:/Users/bjpic/eclipse-windows/SoftAP1/main/softap_example_main.c
Language: GNU C
Index Version: 219.0
Build Configuration: Configuration
Context: file:/C:/Users/bjpic/eclipse-windows/SoftAP1/main/softap_example_main.c
C, {}
Versions in Index: 1
C: {}; 4 macros, 10 includes, 512 names;
Include Search Path (option -I): <--------- Note
This is the contents of the project indexer preferences org.eclipse.cdt.core.prj-SoftAP1.prefs but I have tried numerous permutations thereof.
eclipse.preferences.version=1
indexer/indexAllFiles=false
indexer/indexAllHeaderVersions=false
indexer/indexAllVersionsSpecificHeaders=
indexer/indexOnOpen=true
indexer/indexUnusedHeadersWithAlternateLang=false
indexer/indexUnusedHeadersWithDefaultLang=false
indexer/indexerId=org.eclipse.cdt.core.fastIndexer
indexer/preferenceScope=0
indexer/skipFilesLargerThanMB=8
indexer/skipImplicitReferences=false
indexer/skipIncludedFilesLargerThanMB=16
indexer/skipMacroReferences=false
indexer/skipReferences=false
indexer/skipTypeReferences=false
indexer/useHeuristicIncludeResolution=false
// If possible, attach a picture of your setup/wiring here.
Code to reproduce this issue
Any example (i.e. blink)
Debug log goes here, should contain the backtrace, as well as the reset source if it is a crash.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is too long.
The text was updated successfully, but these errors were encountered: