Unexpected RCP reset (RESET_OTHER) and repeated "dropping radio frame: Parse" errors when using ESP32-S3 + ESP32-C6 Border Router (TZ-1971)

[kunjsn123]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

I expected the RCP (ESP32-C6) to operate continuously without unexpected resets, and UDP multicast messages to ff02::1 to be sent successfully without triggering errors or aborted transmissions.

Actual behavior (suspected bug)

Instead, the RCP resets unexpectedly with RESET_OTHER while showing repeated

dropping radio frame: Parse

messages. After each reset, the Border Router attempts recovery (RCP recovery is done) but the error reappears shortly after. This results in dropped UDP multicast packets and interrupted communication.

Error logs or terminal output

E (470699) OPENTHREAD: dropping radio frame: Parse
E(470700) OPENTHREAD:[C] P-RadioSpinel-: Unexpected RCP reset: RESET_OTHER
W(470701) OPENTHREAD:[W] P-RadioSpinel-: RCP failure detected
W(470702) OPENTHREAD:[W] P-RadioSpinel-: Trying to recover (1/3)
E(470705) OPENTHREAD:[C] P-SpinelDrive-: Software reset co-processor successfully
I(470723) OPENTHREAD:[N] P-RadioSpinel-: RCP recovery is done
I(470766) OPENTHREAD:[N] MeshForwarder-: Failed to send IPv6 UDP msg, len:90, chksum:62f7, ecn:no, to:0xffff, sec:no, error:Abort, prio:net
I(470768) OPENTHREAD:[N] MeshForwarder-:     src:[fe80:0:0:0:c8a9:bd44:d392:5380]:19788
I(470769) OPENTHREAD:[N] MeshForwarder-:     dst:[ff02:0:0:0:0:0:0:1]:19788

Steps to reproduce the behavior

Set up ESP32-S3 as Thread Border Router host (esp-thread-br example) and ESP32-C6 as RCP (RCP firmware from esp-thread-br).

Start the Border Router application.

Send periodic UDP multicast packets to ff02::1 port 19788 from Wi-Fi or Thread side.

Within a few minutes, observe RCP reset events and repeated error logs.

Project release version

latest

System architecture

Intel/AMD 64-bit (modern PC, older Mac)

Operating system

Linux

Operating system version

ubuntu 24

Shell

other (details in Additional context)

Additional context

The problem seems correlated with frequent UDP multicast to ff02::1, but resets may also occur with other traffic.

This may be related to buffer handling or RCP transport stability when processing multicast frames.

The issue occurs even with light traffic load, suggesting it’s not just congestion.

[chshu]

@kunjsn123 Are you able to reproduce the issue on the ESP Thread BR board using the latest code base? If yes, could you share us the IDF commit ID and reproduce steps?

[zwx1995esp]

Hi @kunjsn123 may I ask that do you have any updates on this issue?

[kunjsn123]

Hi @chshu,

I can still reproduce the issue on my setup with the latest esp-thread-br example (IDF v5.4.x) and the provided ESP32-C6 RCP firmware.

Hardware setup:

• Host: ESP32-S3 dev board running the Thread Border Router
• RCP: ESP32-C6 dev board running ot-rcp
• Power rails are common

I’ve also attached the interface connection image that shows the S3 ↔ C6 header mapping I’m using.

Wiring between S3 (host) and C6 (RCP):

• EN ↔ S3_GPIO7 (reset)
• BOOT ↔ S3_GPIO8
• TXD0 ↔ S3_GPIO17
• RXD0 ↔ S3_GPIO18
• plus 5V and GND

I did not connect the other lines in the header (PTA signals, SPI pins, etc.).
There are also no CTS/RTS flow control lines in this connection, so the UART link is currently running without hardware flow control.

Observed behavior:
After sending periodic UDP multicast packets to ff02::1 (port 19788), I see repeated logs:

OPENTHREAD: dropping radio frame: Parse
OPENTHREAD:[C] P-RadioSpinel-: Unexpected RCP reset: RESET_OTHER
...
RCP recovery is done

The cycle repeats after each recovery.

Questions:

1. Is this wiring (EN/BOOT/UART0 TX/RX only, no CTS/RTS) officially supported for ESP32-S3 ↔ ESP32-C6 RCP communication at default UART settings?
2. Are there recommended CTS/RTS pins or any required additional signals for reliable operation?
3. If hardware flow control is not used, what UART baud rate should be set on both sides to avoid buffer overrun and Spinel frame “Parse” errors?

It seems that missing flow control may be causing Spinel frame corruption, leading to RESET_OTHER and recovery loops.
Could you please confirm if this matches the expected behavior for UART setups without CTS/RTS?

Thanks!

[zwx1995esp]

@gytxxsy PTAL for this issue.

[gytxxsy]

@kunjsn123
Regarding your three questions:

1. In our standard example, UART usage only includes TX/RX, with EN/BOOT used for RCP update. CTS/RTS are not used in our example.
2. When using UART, six connections (TX, RX, EN, BOOT, VCC, GND) are sufficient for running the border router.
3. The UART baud rate should be set to 460800.

I tested this issue based on IDF v5.4.2 and IDF v5.4.3, but could not reproduce it. Could you please provide more detailed reproduction steps?
Alternatively, I have several debugging suggestions and questions:

1. From the logs you provided, it appears that the RCP experienced an unexpected reboot, which doesn’t seem likely to be caused by sending broadcast packets. Have you tried using another ESP32-C6 or an ESP32-H2 to reproduce the issue, to confirm that it’s not hardware-related?
2. The address ff02::1 and port 19788 are quite special — OpenThread itself uses them to broadcast MLE messages. What exactly do you mean by “UDP multicast packets to ff02::1 (port 19788)”? Are you actively sending custom messages from BR to ff02::1 (port 19788) on the Thread or Wi-Fi devices?