I have run into unexpected consequences when I changed (on one project) the platformio.ini entry:
platform = espressif32
To - platform = espressif32@4.4.0
I then recompiled (it took considerable time) and uploaded the project to my ESP-WROOM-32 ESP32 ESP-32S Development Board and the project no longer executes properly and throws a pile of errors starting with:
- [ 14595][E][WiFiClient.cpp:516] flush(): fail on fd 48, errno: 11, “No more processes”
Keep in mind that this project was an exact clone of a project that was working fine. Now I get this same behavior on the original and this cloned project.
I have made a third new project for which the code is an exact clone and am getting the same errors. I thought that changing the Platfom.ini for one project would only affect that one project. Wow was I wrong with that assumption!
Any help that gets me back to the configuration associated with platform = espressif32 across all of my projects is very much appreciated.
Well what was the previous espressif32 platform version? What espressif32@.. folders are there in C:\Users\<user>\.platformio\platforms?
Here is the index of that folder:
Okay. Does your project work again when you use platform = espressif32@3.5.0 in the platformio.ini?
Yes it does! Wow, I spent 2 days searching the internet to find a potential solution and you provided one in minutes. Amazing! I’m new to PlatformIO but am quickly finding that this IDE is allowing me to create some pretty amazing capabilities with ESP32s and supporting modules. Now I’m back in the game. Thank You again for the excellent help!
To get back to the “writing platform = espressif32 gives 3.5.0” behavior, you should be able to delete the espressif32 folder and rename espressif32@3.5.0 to just espressif32.
Of course, it would also be good to find out why your sketch fails to run on the latest Arduino-ESP32 2.x core version and only likes running on 1.0.6 (which is what @3.5.0 gives you).
Will do. And that might solve my issue of the fact that while the code to integrate Telegram Messenger compiles without error, no text messages end up being received by the bot. If I understand you correctly, in order to properly reference version espressif32@4.4.0, I’ll create a new project using board “DOIT ESP32 DEVKIT V1” rather than “Espressif ESP32 Dev Module”.
Hi, I’m getting the same error in the same place. I’m using VS Code + PlatformIO + Expressif 32 6.0.1 + az-delivery-devkit-v4 board
I’ve simplified my project to the bare minimum in an attempt to track down this bug. The project activates Serial and WiFi and then proceeds to send GET requests to a REST server. The server responds with JSON that is between 700 bytes to 2.6kb. The GET is issued about every 3 seconds.
After approximately 430 iterations (retrieving about 600kb), the socket fails and regardless of closing the connection, the connection cannot be recovered. It looks like a memory leak and is 100% repeatable. I was using httpclient and getting the error reported in WiFiClient.cpp. Doubting WiFiClient.cpp, I wrote my own http client where I’m in control of the resources.
However, the socket still fails after ~430 calls and ~600kb downloaded from the server. This suggests the problem is deeper in lwip/socket.
I guess I’ll try to wind back to Expressif32@3.5.0 - it’s only a year old, but 3 whole versions. What will I be missing?
Any thoughts on how to solve this are always appreciated. If rolling back is the solution, how do we get 6.0.1 fixed?
Did you report your minimal reproducible example to Issues · espressif/arduino-esp32 · GitHub to get the bug fixed at the source?
Nope but I will (I’m new in this community and have to work out what is where)
First observations: The sockets in 3.5.0 behave noticeably differently. Where under 6.0.1 a single call to recv would normally hoover up the entire response from the REST server, http header, content and all (the sort of behaviour I expect from raw sockets). Under 3.5.0, recv returns exactly the http header and a second call to recv returns the content. There must be some built-in http logic looking for the double CR.
I have to wait another 20 minutes before I reach my 430 call limit. I guess I could have pounded the REST server a little more frequently.
It was looking good for a while, sailing past 430 iterations and 600kb. It threw a Guru Meditation at 561 iterations and 671kb transferred 
.
My test does “keep-alive” the socket. Is there a keep-alive limit built into http?
Strange things are afoot at the Circle K. I prepared an absolute bare minimum example using httpclient and the crash has totally disappeared. It did 2000+ hits on the REST server without a hiccup. Back to the drawing board.
