mirror of
https://github.com/esphome/esphome.git
synced 2026-09-14 16:48:40 +00:00
J. Nick Koston
df51f4e371
The previous LwIPLock for RP2040+Ethernet only called ethernet_arch_lwip_begin/end, taking the async_context lock but never bumping arduino-pico's __inLWIP counter. The W5500 GPIO IRQ path (LwipIntfDev::_irq) checks __inLWIP to decide whether to defer packet processing; with __inLWIP == 0 it would proceed to run _lwipCallback immediately from IRQ context even while the main thread held the async_context lock, re-entering lwIP and corrupting pbuf chains. The corruption surfaced later as the pbuf_cat assertion "p->tot_len == p->len (of last pbuf in chain)" panicking the device on wiznet-w5500-evb-pico boards configured with an interrupt pin. Mirror arduino-pico's LWIPMutex (cores/rp2040/lwip_wrap.h) exactly: bump __inLWIP, take the lock, and on release re-unmask any GPIO IRQs that were deferred while we held it (__needsIRQEN). We can't write `using LwIPLock = LWIPMutex;` in core/helpers.h because pulling lwip_wrap.h there transitively poisons many translation units with lwIP types in an order that breaks err_t resolution, so the body is inlined in the rp2040 helpers.cpp where the include is scoped.
