ESP32 Forum

This is odd that so many people are having this issue. I just created the project and it build fine for all Launch Targets. I will say that I am using Eclipse 2022-09 and IDF Eclipse Plugin Version: 2.7.0.202211101524 because anything later causes me issues with Eclipse hanging.

My best suggestion would be to go to your home directory (C:\Users\your_account_name on Windows) and remove the .espressif folder then go to the menu Espressif->ESP-IDF Tools Manager->Install Tools and select your ESP-IDF location to force a reinstall.

I just created the project and it build fine for all Launch Targets.
My best suggestion would be to go to your home directory (C:\Users\your_account_name on Windows) and remove the .espressif folder then go to the menu Espressif->ESP-IDF Tools Manager->Install Tools and select your ESP-IDF location to force a reinstall.

Build is not a problem, it works for all of us I believe. But opening a project file which uses CHIP_FEATURE_BLE or similar macros even after build causes it to be marked as error.

Deleting .espressif folder is not a good idea. I have like 5-10 different idf versions which I would have to download again.
Cleaning the project cleans the error for me until I open the file again, but there is obviously some unexpected behaviour when using these macros.

I don't believe the IDF is stored in the .espressif folder. The IDF libraries are stored elsewhere but the .espressif folder is used to install the IDF build tools for the IDE. Just as a test, try renaming .espressif to .espressif-save and then reinstall it from your stored IDF directory and see if that fixes the issue.

I actually keep 2 .espressif folders around and when I change the IDF version I'm working on from 4.4.4 to 5.0.1 I name the one I am not using .espressif-4.4.4 or .espressif-5.0.1. I have concerns about tool versions overlapping and would rather keep them completely separate to avoid any issues. When I change the .espressif folder I also reinstall the tools via the IDE and keeping these folders around makes the "Install Tools" a lot quicker than doing a full reinstall of the tools.

Are you not able to compile OR is Eclipse just showing a red error on the line of code? I have had issues where the indexer is confused and Eclipse shows an error but the program compiles and runs just fine.

I am doing some research on an api and created a new hello_world app to test it before I include it in my app. After building it is showing the error in the IDE

Symbol 'CHIP_FEATURE_BT' could not be resolved

However the app does compile and run just fine. Having experienced this type of error before I first attempted to close and reopen the app and rebuild the index but that didn't work. And then I remembered I have seen silly things like this in the past so I moved
above
And the error in the IDE cleared. Mind you this never prevented the code from running, but I hate seeing red in the IDE too so I understand how annoying it can be. Let me know if this fixes your issue.

I don't believe the IDF is stored in the .espressif folder. The IDF libraries are stored elsewhere but the .espressif folder is used to install the IDF build tools for the IDE.

Yea, still downloads lot of stuff, mine has 16GB now.

I actually keep 2 .espressif folders around and when I change the IDF version I'm working on from 4.4.4 to 5.0.1 I name the one I am not using .espressif-4.4.4 or .espressif-5.0.1. I have concerns about tool versions overlapping and would rather keep them completely separate to avoid any issues. When I change the .espressif folder I also reinstall the tools via the IDE and keeping these folders around makes the "Install Tools" a lot quicker than doing a full reinstall of the tools.

Well, you should not need to reinstall or rename anything. Tools are versioned for that reason after all - to use correct specified and tested version. When I switch IDF version I use different workspaces or even Eclipse executables to avoid confusion. If in terminal, I simply export different IDF folder and source its export.sh script to set the environment for that terminal process.

Btw, what I also learned is that it is safer not to change IDF version for existing project at all. If I want to try new IDF version, I copy the project sources to new location, delete all genetated files (including eclipse project settings) and import to new Eclipse workspace with new IDF setup. Otherwise eclipse could use some cached files from previous version and things get messy. It also happened that I had to switch back to previous IDE version (especially v4/v5 change), so it is good to keep your already working project untouched.

... so I moved

Code: Select all

#include "esp_chip_info.h"

above

Code: Select all

#include "freertos/FreeRTOS.h"

And the error in the IDE cleared.

Yea, just the error markers in Eclipse. Ok this is interesting - I moved #include "esp_chip_info.h" as first include of the affected file and the error markers immediatelly dissapeared.

I would still like to know why this happens and whether this is expected or not, but thanks for the tip, this looks much better now.

Well, you should not need to reinstall or rename anything. Tools are versioned for that reason after all - to use correct specified and tested version. When I switch IDF version I use different workspaces or even Eclipse executables to avoid confusion. If in terminal, I simply export different IDF folder and source its export.sh script to set the environment for that terminal process.

Interesting. I had always kept my same workspace and switched IDFs. I understand the tools are versioned but by keeping the .espressif folders separate it removes the previous, no longer used versions of the tools. My .espressif folder is 3.5GB. And once I migrate everything to 5.0.1 I will remove .expressif-4.4.4 which is very close to happening.

Btw, what I also learned is that it is safer not to change IDF version for existing project at all. If I want to try new IDF version, I copy the project sources to new location, delete all genetated files (including eclipse project settings) and import to new Eclipse workspace with new IDF setup. Otherwise eclipse could use some cached files from previous version and things get messy. It also happened that I had to switch back to previous IDE version (especially v4/v5 change), so it is good to keep your already working project untouched.

Yeah, changing the IDF version for an existing project doesn't work, I learned that a while ago. I typically check out a copy of the project into my workspace, switch the .espressif folder, perform a tool reinstall so Eclipse has the correct versions and doesn't use a cached version (it is very quick when you swap the .espressif folder) and then import the project. I will also right click on the newly imported project and "Close Unrelated Projects" so I don't get confused and accidentally try to build a project I don't mean to. Fortunately I don't need to do this very often. Once I migrate I don't ever look back as my user base gets updated OTA.

However, the closing and reopening of projects with IDE plugin 2.9 has a fatal flaw and will end up hanging the IDE when reopening projects. That is how I ended up back on this forum. I asked about it here viewtopic.php?f=40&t=32927 and got not response so I ended up submitting a bug report here https://github.com/espressif/idf-eclips ... 8922148584 and a pull request that fixed it was approved very recently. I'm still on plugin version 2.7 but will test this update soon.

Glad moving the import worked for you. I had this happen once before viewtopic.php?f=40&t=22819 As I recall I submitted a bug report for this at one point and it ended up getting fixed with a change to their indexer. But with that issue it only looked bad in the IDE. Since 5.0.1 it will now pop up a window and tell you there is an error and ask you if you want to proceed. You then have to go back and look at the build output to see if there really was a build/link error. I wish they would change it back to only using errors from the build console rather than errors reported by the IDE/indexer.

I used to switch whole eclipse executable, whcich is ussually < 300MB of already downloaded data, quite recently I realized that switching the workspace should be enough. But the point is the same - make Eclipse not to use cached resources.

Part of it comes from the fact that I should ideally be able to do reproducible builds with no external dependencies, so anyone can fetch the archive and create exactly same binary output if following correct steps even years later. I know that it is impossible with IDF v4 and v5 only comes closer to make it possbible, but having to download anything is big risk IMO as you don't know if someone decides to just delete obsolete unsupported version or just rename the path.
I just realized your approach of renaming the .espressif could actually help me in this as I could back it up locally for only the specific IDF version.

However, the closing and reopening of projects with IDE plugin 2.9 has a fatal flaw and will end up hanging the IDE when reopening projects. That is how I ended up back on this forum. I asked about it here viewtopic.php?f=40&t=32927 and got not response so I ended up submitting a bug report here https://github.com/espressif/idf-eclips ... 8922148584 and a pull request that fixed it was approved very recently. I'm still on plugin version 2.7 but will test this update soon.

Yes, I can confirm this one...

Since 5.0.1 it will now pop up a window and tell you there is an error and ask you if you want to proceed. You then have to go back and look at the build output to see if there really was a build/link error.

Exactly, quite annoying.

I wish they would change it back to only using errors from the build console rather than errors reported by the IDE/indexer.

Do you mean the way how it was with legacy make? It may have been a bit more difficult to get familiar with for a newbie, but I ended up having the build environment pretty well under my control. I sort of lost that level of control when switching to Eclipse plugin with Cmake, but I'm slowly learning how to "bypass" the automated stuff and make it do thing as I specify (like Component manager, for example).

So, as a side note, while searching for some absolutelly unrelated problem I came across following issue where the esp_chip_info.h is also mentioned and suggested to move to the top as workaround: https://github.com/espressif/idf-eclips ... 1352930445

Do you mean the way how it was with legacy make?

No, I don't mind cmake, I was just referring to how when it finds an error in the IDE it will prompt you saying there was an error building and asking you if you want to proceed to deploy when in fact there was not a build problem, just an index problem. It actually seems to only happen if there is an index issue in the build subdirectory. I have had it happen more than a few times but haven't paid enough attention to exactly pinpoint the index error.

So, as a side note, while searching for some absolutelly unrelated problem I came across following issue where the esp_chip_info.h is also mentioned and suggested to move to the top as workaround: https://github.com/espressif/idf-eclips ... 1352930445

Oh that is interesting. This is exactly the error I am talking about above. The problem tab fills with errors, the popup is displayed however there is no build problem and the project runs fine. It is interesting because I was using plugin version 2.7 until yesterday when they committed the PR to fix the hanging problem and now I'm running a home built version of the plugin version 2.9.1. I'll have to watch and see if it still happens. I'm going to update to the nightly build today when I get a chance.

+1 for me with this issue.

I installed the IDE from "Espressif-IDE-2.11.0-win32.win32.x86_64.zip" and followed the instructions *exactly*. I created a new project from the "hello_world" example. It builds correctly, but shows the following in "Problems":
It would be really nice if we could follow the instructions exactly as described and end up with an environment that works correctly.