Allow exiting `AT+MQTTPUBRAW` data input mode using existing '+++' exit data mode or timeout

[mAliGem]

Is your feature request related to a problem?

In high throughput scenarios and especially when the host is sending lots of data (multiple KB's) while the ESP-AT module is also sending multiple KB's, data can be corrupted (EMI + cross-talk) and potentially, not read. The C5 remains unresponsive until the number of bytes is read as specified in the MQTTPUBRAW command.

I am unable to use UART control pins in my current configuration. I have an esp32-WROVER host and an esp32-c5 as the ESP-AT module.

I use a baudrate of 460800, 8 data bits, 2 stop bits.

Describe the solution you'd like.

I would like either the ability to exit data mode using the existing +++ escape sequence used for TCP/UDP.

Adding another field to the MQTTPUBRAW that describes the reading timeout for data would also be acceptable.

Describe alternatives you've considered.

I've tried using +++ sequence to exit MQTTPUBRAW data mode however, it doesn't work.

I am in the process of writing my own equivalent AT command that does basically the exact same thing but also has a reading timeout.

Below is an attached image that shows that the host was trying to send the +++ sequence however, that it wasn't working. Attached is a logic analyzer trace with timings that highlight a similar scenario where sending the +++ doesn't seem to work. The topic names have been obscured with 'xxxx...'

MQTTPUBRAW Trace +++ fail - test2(1).csv

This shows the start and end of the above messages in the table.

This shows detailed form of the +++ being sent along with the timings:

Here is a preview of what is eventually sent if the byte limit is reached. I have x'd out topic names. You can clearly see that +++ are being sent.

Additional context.

I would've thought that +++ would've worked out of the box for MQTTPUBRAW considering the fact that the pattern detection is present in at_uart_task.c however, I can't seem to trigger it.

Also note that I am using interface security (AES-CTR over UART) and I have tried both sending the exit command as raw bytes and in the encrypted form. Neither seem to work.

[ustccw]

@mAliGem Thanks for your detailed report and context.
From your description, the root issue stems from environmental EMI noise combined with the lack of UART hardware flow control. While software workarounds can offer some mitigation, relying solely on software to handle physical layer signal degradation rarely yields ideal results:

• Data Corruption & +++ Reliability: If EMI is causing byte loss or corruption on the wire, the +++ escape sequence itself is equally vulnerable to being corrupted during transmission, making it unreliable as a guaranteed recovery mechanism.
• AT Command Timeout Support: Adding a command/data reading timeout is unfortunately non-trivial to implement in the short term. It involves not just UART-level timeouts, but also MQTT protocol state management which relies on underlying LwIP stack behaviors.

That said, we acknowledge the pain point when data bytes are lost on UART during AT+MQTTPUBRAW. We will consider adding support for the +++ escape sequence in AT+MQTTPUBRAW to allow users to force-exit data mode in such recovery scenarios. We will keep you updated once there is any progress on this feature. Thanks again for helping us improve ESP-AT!