Hi All,
I've just downloaded the latest library updates to the Arduino IDE (v2.3.2), which I noted included ESP32 updates.
Now ESP32 chip inquiries such as esp_chip_info_t, esp_chip_info, chip_info, etc. now won't compile, being rejected as 'not declared in scope'.
I'm compiling for the ESP32-S3.
Has anyone else come across this problem?
Thanks for any advice...
Add:
#include "esp_chip_info.h"
1 Like
There is also this: https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/Esp.h
It can return a string, for example: "ESP32-D0WDQ6" or "ESP32-S3".
I tried to check the build version:
Serial.print("Core (is build version): ");
Serial.println(ESP.getCoreVersion());
But that didn't exist in version 2.
Here is a small test: Get build version of ESP32 - Wokwi ESP32, STM32, Arduino Simulator
Brave man! The ESP32 Arduino core has been updated to 3.x. There are a number of breaking changes. See Migration from 2.x to 3.0 - - — Arduino ESP32 latest documentation
I'll be looking at it soon for the I2S and time functionality but may also wait a bit to see what problems other users report.
Thanks gfvalvo.
That #include "esp_chip_info.h" seems to have some effect, as I'm now not getting the "esp_chip_info_t out of scope" compile errors anymore, but it now comes back with another compile errror for "spi_flash_get_chip_size" not considered to be in scope.
Any ideas on what .h file might address this problem?
And how did you identify that the previous problem would be addressed by the esp_chip_info_t header?
Also, noting your comments, 6v6gt, that the ESP32 Arduino core has been upgraded to 3.x, now makes me worried that I'm facing a cascade of whack-a-mole compile errors, where I fix one set, only have another set pop up.
A bit unsettling...
You can always downgrade to Core 2.x.
Well, perhaps, but:
(i) Aren't we supposed to be always upgrading, riding bigger unicorns and finding bigger rainbows, and
(ii) Support for core 2.x stops in July 2024, so it seems imperative to make the move sooner rather than later?
(i) only when your current unicorn is to small
(ii) you could do the move when others report that they have already successfully found the bigger unicorn.
Unfortunately this is the case with all new releases of software. The early pioneering users will hit bugs and dutifully report them and the software improves. In this case, that is the ESP32 Arduino core, there will be breaking changes because the code comes down stream from Espressif and interfaces etc. there have changed. The Arduino core sits at the tail end of multiple abstraction layers in the manufacturer's platform and cannot protect its users from all changes while still offering support for new boards etc. There have been pre-release versions of the ESP32 Arduino 3.x around for some time which should have given library writers and even general users an opportunity to test/adapt their applications.
What you, as an early user, can do is to report any issues you encounter on the appropriate github page, either GitHub - espressif/arduino-esp32: Arduino core for the ESP32 or that of a specific library as appropriate. The alternative, already mentioned, is to roll back to an earlier release and wait until it is more mature.
Incidentally, I for one do not automatically accept the (rather persistent) invitation in the IDE to update libraries and platforms and this can even be suppressed. See Downgrade from v3.0.x to v2.0.x - #2 by ptillisch
Well, my current unicorn has just been ripped out from under me, I'm afraid...
Yes, I guess so, and indeed, I'm now in a whack-a-mole cycle...
- The #include "esp_chip_info.h" (seemed to) solve the esp_chip_info_t issue,
- But then the spi_flash_get_chip_size issue came up,
- Solved that by finding that (back in 2022?) #include "esp_spi_flash.h" should be replaced with #include "esp_flash.h", which I did.
And then I find that the spi_flash_get_chip_size function has been superceded by a new command, esp_flash_get_size, that needs the specification of a variable to take the chip size, with the following lines :
uint32_t size_flash_chip;
esp_flash_get_size(NULL, &size_flash_chip); - Did another compile, and find that while the spi_flash_get_chip_size issue doesn't cause a compile error anymore, there's a new error:
'mbedtls_md5_starts_ret' was not declared in this scope; did you mean 'mbedtls_md5_starts'?
And this is apparently in the ESPAsyncWebServer\src\WebAuthentication.cpp file, which I would have though would be a well-defined and stable file. I've got the latest version of ESPAsyncWebServer installed, but it looks like I'm now going into the WebAuthentication.cpp file and altering mbedtls_md5_ commands, as described by FranBachiller (Reddit - Dive into anything)
...WTF??!!
I'm going through a lot of toilet paper trying to get this code to compile (which had been doing perfectly well before these latest ESP32 Core updates)...
I really could think of many better things to do with my time...
Just check that this is the library that you are using: GitHub - me-no-dev/ESPAsyncWebServer: Async Web Server for ESP8266 and ESP32 at the latest version because I see there is also a fork lying around. There appear to have been some recent changes to make it compatible with ESP32 Arduino core 3.0.0 an this closed issue appears some similarities to your current problem: Compilation Error for Newer ESP32 · Issue #1414 · me-no-dev/ESPAsyncWebServer · GitHub
The most I would do here, if that does not help, is to report an issue in the github library and revert back to the earlier 2.x release.
Thanks, and Interesting point, 6v6gt.
The 'standard' ESPAsyncWebServer library downloaded by Arduino IDE 2.3.2 is the one by lacamera.
The one you reference is by me-no-dev, and looking at the WebAuthentication.cpp file in this version has an updated set of lines that tries to detect if the later ESP IDF version is being used, and sets the mbedtls_md5 functions accordingly:
#if ESP_IDF_VERSION_MAJOR < 5
mbedtls_md5_starts_ret(&_ctx);
mbedtls_md5_update_ret(&_ctx, data, len);
mbedtls_md5_finish_ret(&_ctx, _buf);
#else
mbedtls_md5_starts(&_ctx);
mbedtls_md5_update(&_ctx, data, len);
mbedtls_md5_finish(&_ctx, _buf);
However, I have ecstatic news, and that is I finally whacked the last mole, and the code now compiles(!). Wonderful.
But there was one more compile error that came up before I reached this Nirvanic state, and that was the function ets_printf needed to be changed to Serial.printf in the AsyncEventSource.cpp file.
Once this was done, rainbows and unicorns came bursting over the horizon!
However, checking the AsyncEventSource.cpp file in me-no-dev's distribution shows that ets_printf still exists there, and hasn't be updated to Serial.printf.
So it looks like there's probably still going to be a number of blind men stumbling around in a dark room looking for a black cat, yet, as more of these pot holes come to light...
Uh oh.
The Arduino IDE library manager wants to download ESPAsyncWebserver by lacmera
which is a fork of ESPAsyncWebserver by ESPHome
which in turn is a fork of ESPAsyncWebserver by me-no-dev.
The latter, that is by me-no-dev, appears to be the most up to date.
The one by lacmera, the official one, has not been touched for 10 months and appears to have the issues button disabled.
The one by ESPHome appears also to have some 3.x issues solved.
Anyway, thanks for providing a documentation trail of your experience here. It may help others.
TAGs: ESPAsyncWebserver; ESP32 Arduino 3.x compatibility issues;
No problems, and thanks for everyone's responses to my queries.
It sounds like you had a project that wasn't broke but you decided to "fix" it anyway.
What was the compelling reason for upgrading?
This doesn’t seem compelling:
To me that simply means that they’ll stop providing bug fixes on the previous branch. But if you project is already working, so what?
Perhaps this:
That indicates you have the mindset of an early-adopter. You’re willing to put in the time being a “beta tester” when the newest shiny object is released and it’s OK if that requires reworking a previously-functioning project.
That willingness is actually helpful to those of us who prefer to hang back a little and let others work out most of the bugs and mandatory changes. So, thanks.
Yes, you're right, I'm being a bit of a muggins to just accept, and try and work with new libraries.
I usually figure that I'm probably going to be forced into using some feature of the new libraries at some stage in the future, and I'd rather get a handle on it earlier, while I can give it the time, than get caught flat-footed at the last minute when I want to implement something using the new library.
But, having rationalised that away, I've found more problems coming out of my code, because I'm using a TFT display and Bodmer's tft_espi library, and it's hitting problems, going into an endless Guru Meditation runtime error.
Some other folk have reported related problems with Core 3.x and tft_espi (although they seem to be compilation errors rather than runtime errors), and I have tried incorporating their proposed fixes, but to no avail...
Maybe ESP32 Core 2.x ain't such a bad place to be afterall...
In addition to the migration guide for the breaking changes made to the API of the version 3.0.0 "esp32" boards platform which was shared by @6v6gt earlier in the thread, you will also find the ESP-IDF 5.x migration guides to be a useful reference:
The ESP-IDF framework is a dependency of the "esp32" boards platform. That dependency was bumped from version 4.4 to 5.1 in the 3.0.0 release of the "esp32"
platform, so you are faced with the breaking changed made in the ESP-IDF 5.0 release in addition to the breaking changes in the "esp32" platform's own codebase. I think all the problems you mentioned so far are actually from the ESP-IDF's code.
Yes, you’re probably right, but, because my project uses aTFT display, relying on Bodmer’s tft_espi library, I’ve had to roll back to ESP32 Core 2.0.14 to get that library to work - tft_espi won’t work with any ESP32 core releases higher than 2.0.14, as reported in esp32 2.0.15 and tft_espi keeps restarting esp32c3 mini · Issue #3284 · Bodmer/TFT_eSPI · GitHub.
So, apart from all the issues I was finding with ESPAsyncWebServer operations, my journey trying to work with ESP32 Core 3.x is over, as I need to have the TFT working as well, and, until Bodmer upgrades tft_espi to work with Core 3.x, I’m stuck with 2.0.14.
The library author Bodmer said this about 2 weeks ago for something similar: Compilation error after update to ESP32 library to 3.0.1 · Bodmer/TFT_eSPI · Discussion #3361 · GitHub
Summary: you'll have to wait for any update.