ESP32 Forum

We've been using ESP-IDF of various versions (currently 5.0.3) with cellular and other modules via UART, using the built-in ESP-IDF uart driver (i.e. with uart_driver_install(), and an event queue size of 20) for years now, never had a problem with it ever, rock solid.

However, we've just started using the ESP-IDF built-in IP stack, connecting the bottom of LWIP's PPP to our module transport, and when we do that we very frequently get:
There are no changes to our UART or driver code, they are doing what they always did, just passing PPP frames now. There is no increase in logging output, all about the same. The only difference is that LWIP is now active. The errors get so bad that nothing gets through the IP stack and our tests fail. We have tried, experimentally, doubling the event queue size passed to uart_driver_install() and that doesn't help, the task serving the UART event queue is evidently being blocked for too long.

Question: is there something inside the LWIP stack, preferably something we can tune, which could be hogging CPU?

Answer: turns out that the event queue full situation has always been there, it is just that when debugging the PPP stuff we switched on CONFIG_LOG_DEFAULT_LEVEL_VERBOSE and it became visible: seems to be TX DONE or some such pouring out when we send stuff over the UART, which we don't care about and actually doesn't matter (until a logging print is spat out).

The real problem was that one of our tests terminated a PPP session in a way that LWIP objected to, LWIP wasn't terminated properly and hence would not receive any data again from that point onwards.