esp_modem freezes when flow control is enabled and module is unresponsive (IDFGH-12739)

[antfarming]

Answers checklist.

• I have read the documentation for esp-protocols components and the issue is not addressed there.
• I have updated my esp-protocols branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

When flow control is enabled, and the cell module is not ready to receive uart commands, the uart_tx_all function found in uart.c will get stuck. I was able to prove this by adding some simple debug. "ring bug send ok" will not execute once the ring buffer is full.

       while (size > 0) {
            size_t send_size = size > max_size / 2 ? max_size / 2 : size;
            ESP_LOGI("T", "ring buf try send");
            xRingbufferSend(p_uart_obj[uart_num]->tx_ring_buf, (void *) (src + offset), send_size, portMAX_DELAY);
            ESP_LOGI("T", "ring buf send ok");
            size -= send_size;
            offset += send_size;
            uart_enable_tx_intr(uart_num, 1, UART_EMPTY_THRESH_DEFAULT);
        }

I am seeking advice on the best way to prevent this from happening. I would ideally not like to modify uart.c.

If CTS is not ready, and you issue enough AT commands, the calling task will get stuck and will never recover.

While the goal would be to never be in a position when the cell module will not respond, it is entirely possible that it can happen. For example, if you are unsuccessful in turning the module on. Or if you wake up and the module is still in data mode.

My interim solution has been to modify esp_modem to be able to do flow control with only RTS, thus you are still able to slow the module down during OTA.

[david-cermak]

I think I understand the problem and see that neither the modem layer nor the uart driver accounted for this situation.
General solution would be to add a send timeout to the Tx path as well, similar to generic socket API (write only if a socket is writable). On the modem layer, we'd just try to send an AT command (with a certain timeout) and fail even if we're not able to transmit within the timeout, now we'd just get stuck.

I don't think we'd address this issue generically enough however (might be that we'd add an API to check whether the ringbuffer is full or so).
I'd suggest looking into practical solutions for now, such as:

• persist the modem settings with AT&W or similar, so the flow control is ON after power-up
• checking the RTS signal manually before starting communication, or after wakeup event