ESPAsyncWebServer
ESPAsyncWebServer copied to clipboard
me-no-dev
Required to lock TCPIP core functionality!
The installing the latest 3.1.0 version of ESP32 by ESpressif System continuously restarts the esp32 with the error:
assert failed: tcp_alloc /IDF/components/lwip/lwip/src/core/tcp.c:1851 (required to lock the TCPIP core functionality!)
After reinstalling version 3.0.7, the problem was solved.
@lbernstone Thank you for pointing this out. I reviewed the ESPAsyncWebServer repository, and it seems the issue is indeed related to the "Required to lock TCPIP core functionality!"
confirming I am also getting the same "Required to lock TCPIP" issue on an ESP32-WROOM-32D. Downgrading to the previous version of esp32 by espressif also solved the problem for me.
@sh0rtrange Thank you! I'll try that as a temporary workaround. I really appreciate your input!
3.1.1 - no fix changes, still "required to lock the TCPIP core functionality!"
++ Adding that I see the same on the waveshare esp32 c3 and that downgrade worked. Thank you!
++ Adding that I see the same on the waveshare esp32 c3 and that downgrade worked. Thank you!
Hey can you tell me which version are you using? thank you
++ Adding that I see the same on the waveshare esp32 c3 and that downgrade worked. Thank you!
Hey can you tell me which version are you using? thank you
Hmmm -- investigating this question has shown me that it seems I stopped updates at some point. I have version 3.1.2 of espasyncwebserver. Which means I must have encountered other errors that caused me to stop at this version (and I don't remember why anymore :/)
But confirming that the 3.1.0 to 3.0.7 downgrade of esp sdk fixed the errors.
@me-no-dev My chips were on pioarduino of older version https://github.com/pioarduino/platform-espressif32/releases/download/51.03.07/platform-espressif32.zip without the TCPIP issue.
-
Recently I tried uploading from an esp32 library builder which happened to be based on idf 5.3 and was hit by a problem saying something like asserting TCPIP .... The chips kept rebooting with the error message.
-
Using pioarduino 53.03.11 causes this same issue.
assert failed: tcp_alloc /IDF/components/lwip/lwip/src/core/tcp.c:1851 (Required to lock TCPIP core functionality!)
FYI: you can have a look at the community maintained forks here where several people are collaborating towards maintaining these 2 good libraries with a frequent release cycle:
- https://github.com/mathieucarbou/AsyncTCP/
- https://github.com/mathieucarbou/ESPAsyncWebServer/
This issue is fixed since October 2024 in these repos above and they always tested in CI against latest Arduino RC. Ref: https://github.com/espressif/arduino-esp32/issues/10526
@mathieucarbou I am testing yours. What should I set to get rid of these? I am not familar with RP2040W and only run ESP32 and ESP8266.
In file included from .pio/libdeps/release_upload/AsyncTCP_RP2040W/src/AsyncPrinter.h:51, from .pio/libdeps/release_upload/AsyncTCP_RP2040W/src/AsyncPrinter.cpp:51: .pio/libdeps/release_upload/AsyncTCP_RP2040W/src/AsyncTCP_RP2040W.h:73:4: error: #error For RASPBERRY_PI_PICO_W board using CYW43439 WiFi only 73 | #error For RASPBERRY_PI_PICO_W board using CYW43439 WiFi only | ^~~~~ Compiling .pio/build/release_upload/libeaa/AsyncTCP_RP2040W/AsyncTCP_RP2040W_buffer.cpp.o In file included from .pio/libdeps/release_upload/AsyncTCP_RP2040W/src/AsyncTCP_RP2040W.cpp:104: .pio/libdeps/release_upload/AsyncTCP_RP2040W/src/AsyncTCP_RP2040W.h:73:4: error: #error For RASPBERRY_PI_PICO_W board using CYW43439 WiFi only 73 | #error For RASPBERRY_PI_PICO_W board using CYW43439 WiFi only
What should I set to get rid of these? I am not familar with RP2040W and only run ESP32 and ESP8266.
Read the doc: https://github.com/mathieucarbou/ESPAsyncWebServer/?tab=readme-ov-file#dependencies ;-)
You just miss a flag to handle transitive dependencies correctly depending on the platform used.
@mathieucarbou Your response/reply doesn't help.
However, having re-read the doc,
- "Drop support for ESP8266, which goes EOL in a few years. All ESP8266 boards can be replaced by equivalent ESP32 boards." Not so sure if the future would be so. Hardly any device that could compete with ESP01S relay and ESP8266 is still handy in many applications, particularly with supports from I2C boards.
- Given the above, including your response to my question, anyone, particularly novice layman like me, should stay clear of your "2 good libraries".
@ceewanna : you did not understand. All releases we do will not cease to exist. That is why we have tags and a release cycle.
but we plan on creating a v4 one day that will be only focused on Esp32, because maintaining 8266 and rp2040 has a real cost and clearly what we see is that most users helping are on esp32, and 8266 users are not interested (or do not have the knowledge) to help improve or fix. It does not mean that the 3.x versions will cease to exist. It just means that the next major version that we will start one day will only be esp32 focused.
Our fork contains a lot of fixes and perf improvements, plus middleware support. If you want to be the person improving our current 3.x version for 8266 you are welcomed to help. Like I said, this is a community effort with a frequent release cycle and deployment (what we missed from the original repo) which brings a lot of improvements.
Confirming the @mathieucarbou fork worked for me as a drop in replacement for this lib, allowing me to run my app on the latest arduino-esp32 core 3.1.1. Thanks
@mathieucarbou didn't you promise to PR the changes last year? Just asking...
@mathieucarbou didn't you promise to PR the changes last year? Just asking...
I've looked and the code has changed so much that it would be quicker that you just merge the full content of these 2 repos if you want, and just clean the CI scripts and project descriptors. You can have a look at the commit diff you'll quickly see ;-) There are far more than just this issue that has ben fixed. I cannot do that since you would need to edit the PR before pushing it.
Also, regarding ESPAsyncWS, we kind of abandoned a lot of flash strings for 8266 (a lot are using heap) so if you are picky about a very good 8266 support, you might not like that.
The best thing to do would be to migrate the original AsyncTCP, ESPAsyncTCP and ESpAsyncWebsServer to an org, then merge the forks into them, and add you and me as admin so that we can all tweak the repo settings and commit to a frequent release cycle like we do in the forks, with libraries deployed, and a real CI. We should also both have the permissions to deploy on behalf of the org on PIO registry and add members. This is the only way I see to keep the projects afloat and alive, avoid those many forks, and centralise improvements at one place.
So I'm proposing a joint effort to regroup both, the most important point being: it has to be an org, with members, to ensure continuity of the projects, release, CI and deployment.
Note: I could also spend time to create the org, and move my forks inside if you prefer, but if using the GiHub transfer project feature, it is possible that GiHub will redirect users going to your repo towards the new org, so in that case it might have better value if you do it and then we merge back.
Please come to discord to discuss this further
I am in Discord. Through pioarduino server ?
Maybe best to also join the ESP32 Arduino discord, but I am fine with DM through pioarduino as well
Maybe best to also join the ESP32 Arduino discord, but I am fine with DM through pioarduino as well
I didn't know about it ;-) Where to find its link ?
A server is probably better because you would also need to add @vortigont in the org and server. He is a collaborator in the fork and heavily contributes to both forks.