mirror of
https://github.com/esphome/esphome.git
synced 2026-08-29 09:13:28 +00:00
J. Nick Koston
c7bf312b1b
Two lwIP values on rp2 were copied from ESP32, where MEM_LIBC_MALLOC=1 and MEMP_MEM_MALLOC=1 make them labels rather than caps. On rp2 they are static pools and a fixed heap, so they became hard limits. MEMP_NUM_TCP_SEG is a global pool but was set to TCP_SND_QUEUELEN (17), which is per-PCB. lwIP's sanity check only demands >=, so that is the floor for a single connection: one busy PCB could drain the pool for every other PCB, including the other API connections, mDNS and web_server. Size it to 2x the per-PCB queue instead, which costs about 340 bytes. MEM_SIZE stayed at arduino-pico's 16KB. TCP_OVERSIZE defaults to TCP_MSS, so one PCB holding a full TCP_SND_BUF pins about 6KB; two connections exhausted the heap while api's max_connections on rp2 is 4. Raise it to 32KB, which is arduino-pico's own next tier. Either limit surfaces the same way: ERR_MEM from tcp_write(), then EWOULDBLOCK, then a refused send_message(). The docstring now records why MEMP_MEM_MALLOC=1 is not the answer here, since it looks like the obvious fix and is not. lwIP's heap takes its protection from LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT, which defaults to 0, so under NO_SYS=1 mem_malloc() and mem_free() are unprotected, and memp.c calls mem_malloc() outside SYS_ARCH_PROTECT. Routing RX pbuf allocation through it lets the pendsv IRQ race the main loop on one unguarded free list; that faults within seconds on CYW43. Also fixes two stale comments in api_frame_helper.h that still claimed rp2 uses an 8xMSS send buffer; it has been 4xMSS since #14843. RAM cost on tests/components/bluetooth_proxy/test.rp2040-ard.yaml is 16,724 bytes, leaving about 162KB for the heap.
