Wifi allocation failure

permal
Posts: 370
Joined: Sun May 14, 2017 5:36 pm

Wifi allocation failure

Postby permal » Sat May 25, 2019 12:44 pm

Hi,

I'm experiencing an issue where if there are more than three sockets actively communicating, the Wifi layer fails to allocate memory:
W (20948) wifi: alloc eb len=24 type=3 fail, heap:4107600
The result of this is that communication completely fails from this point; the device appears completely dead from a communication perspective, although it still remains connected to the access point. Further, there is no automatic recovery from this state without forcefully disconnecting the device from the access point via the AP's UI or possibly restarting the Wifi layer programatically.

This seems similar to, or possibly the same, problem for which Jason von Nieda filed ticket #2184 at GitHub and the related forum thread.

My current config (gist):
- CONFIG_SPIRAM_USE = Make RAM allocatable using malloc() as well
- mbedTLS uses SPIRAM, also tried "default alloc mode".
- CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL = 16384
- CONFIG_ESP32_WIFI_TX_BUFFER = Static (no dynamic option available)
- CONFIG_WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST = yes

Reducing CONFIG_SPIRAM_MALLOC_RESERVE_INTERNAL to 4096 made things better, but what other problems does that open up to? Also, the description for this item says:
Note that because FreeRTOS stacks are forced to internal memory, they will also use this memory pool; be sure to keep this in mind when adjusting this value.
What's is this text trying to say? That increasing this too much would prevent task stacks from being allocated?

I suppose the one thing I have to do is to free up internal memory, correct? As I've already moved mbedTLs to SPIRAM via config and enabled SPIRAM to be usable by malloc() (which I assume also includes C++ operator new?), the only thing left to adjust is CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL, right? I've lowered it to 1024 and no longer see the allocation failures even with six active sockets. I'm assuming there is a performance cost to this as a lot more memory access will have to go to SPIRAM instead, but an unstable device is unusable so the cost is worth it I think.

Edit: After additional testing, CONFIG_SPIRAM_MALLOC_ALWAYSINTERNAL made things better but I'm still seeing the allocation errors.

Is there anything else I can/should do?

Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Majestic-12 [Bot] and 21 guests