LWIP read() blocks CPU

[meowsqueak]

I'm trying to integrate the ESP-MQTT library with my ESP-IDF application, which uses FreeRTOS.

https://github.com/tuanpmt/espmqtt

My application has two tasks - one collecting sensor data, the other publishing this data via MQTT to an external broker. In addition, there needs to be a way for MQTT subscriptions to affect the sensor data collection task. I have implemented communication between these two tasks via FreeRTOS queues and this seems to be working correctly.

The problem starts when ESP-MQTT blocks on a `lwip_read()`, waiting for any published data from the broker, with no timeout (blocking). Normally on other systems this would be fine as the OS would sleep the thread/task and wake it up when data becomes available on the socket. But with my app I've found that this blocks the CPU. Other tasks with the same or higher priority are not scheduled and do not run.

I've read that LWIP is able to be mapped onto FreeRTOS tasks and I'd assumed that this would allow for cooperative blocking behaviour, but I'm wondering if that's really the case. Do I need to configure or enable something in FreeRTOS or LWIP to get this to work correctly?

Obviously if I enable the second CPU I can dedicate one CPU to block on `read()`while the other collects sensor data however I'd like to find a way to make this work on a single CPU as I wish to eventually port a version of this application to a single-core micro (ESP8266).

[ESP_Angus]

The problem starts when ESP-MQTT blocks on a `lwip_read()`, waiting for any published data from the broker, with no timeout (blocking). Normally on other systems this would be fine as the OS would sleep the thread/task and wake it up when data becomes available on the socket. But with my app I've found that this blocks the CPU. Other tasks with the same or higher priority are not scheduled and do not run.

I've read that LWIP is able to be mapped onto FreeRTOS tasks and I'd assumed that this would allow for cooperative blocking behaviour, but I'm wondering if that's really the case. Do I need to configure or enable something in FreeRTOS or LWIP to get this to work correctly?

This shouldn't be happening, while a task is blocked on read() other tasks (of both higher and lower priorities, in the order of their priority) should be running.

Are you able to share your code?

[meowsqueak]

I'll put together a small example and share that soon. It will also help me to verify that I'm not making a mistake elsewhere. I'll report back when it's available.

[meowsqueak]

I've confirmed my own error by simplifying my code, switching to "single CPU" mode, and also printing the Core ID to be sure, and a blocking read does not suspend all tasks on the CPU. I think my original problem was related to task priority or a blocked queue.

Thanks for the response and sorry for the noise!