ESP32-C3 - Duplicate UART Tx Data

[FrankSchwab]

Sorry if this has been asked before, but searching the forum fails with a 500 error code, and my normal backup of using Google search of the site didn't find anything.

What I have: ESP32-C3, ESP-IDF 5.1, ESP-Matter 1.1

What I'm trying to do: Use the ESP32 UART port to reflash a secondary MCU.

What I'm seeing: Duplicate lines of data show up in the UART output that I did NOT ask it to send.

Details:
The reflash protocol for our secondary MCU is a primitive, ping-pong, command-reply protocol - the ESP32 sends a 64 byte packet using uart_write_bytes(), waits for a reply, then sends the next 64 bytes. The UART is running at 115,200 baud - fast, but not ridiculous. The reflash image is downloaded in pieces via WiFi, and is on the order of 256KB long. What I see happening is that 4 out of 5 attempts to reflash fail. Looking at the data, a random one of the 64 byte packets (different on every run) are sent twice. I've instrumented my side with debug messages immediately before and immediately after the uart_write_bytes() call, so I log every byte that I request to transmit, as well as looking at the buffer I requested to transmit after the uart_write_bytes() call to verify that it hasn't been stomped on. Everything that I've looked at looks good.

Except that once or twice during most 256KB transfers, one of the 64 byte packets gets sent twice. Using a serial monitor on the lines, I see the packet transmitted from the ESP32, I see the reply come back from the secondary MCU, then I see the same packet go out a second time. The duplicate line appears to replace the correct next line (that my logging shows I called uart_write_bytes with), but the line after that does come out correctly, as do the rest of the lines in the 256KB reflash file. In other words, I send packets 1, 2, 3, 4, and what I see on the line is packets 1, 1, 3, 4

The ESP32-C3 has a 128 byte hardware Tx FIFO, so nothing should be getting buffered in the uart driver. We aren't overrunning the buffer, because only one packet is allowed on the interface at a time, and we wait for a reply before sending the next. I've tried changing the size of the RX/TX buffers (256 bytes, 2048 bytes, 0 bytes (TX)), but nothing seems to change this behavior.

Anyone seen anything like this? I don't really relish the thought of digging into the low-levels of the uart and ring-buffer code in the ESP-IDF.

[ESP_Sprite]

Any chance you can post a (whittled down version to the minimum that exhibits the error) version of your code here?

[FrankSchwab]

If I can't figure out a workaround, I'll do that. Trying to avoid it because it's probably a days worth of work, but I understand that sometimes that's the only way. I was hoping that someone could say "Oh, yeah, we see that all the time and the workaround is....". But I was hoping that my lottery ticket had this weeks numbers too...

[FrankSchwab]

Ah, well, turned out to be an issue between the ESP32 and our secondary MCU, fundamentally caused by pre-emption of my task causing an unexpected timeout on the secondary side. Thanks for looking, but there's no problem here.

[ESP_Sprite]

No problem, glad you found the issue!