RCP Timeout and Crash Under High Command Load (Flooding) with Framing Errors

[VVG1997]

Issue Description
When flooding control commands (e.g., repeated On/Off cluster commands) from the ChipTool APK to a Thread end device (Nanoleaf), the otbr-agent crashes due to an RCP timeout and framing errors in the RCP communication layer.

Tested with Below Configurations
Baud Rate - 115200 and 460800
NCP_TX_BUFFER - 1024 and 4096

Environment
OTBR - otbr-posix (OpenThread Border Router)
Repository: https://github.com/openthread/ot-br-posix.git
Branch: main
Commit: 6112f9802f32c41b15ble331bf391c2c0f86bbc5

RCP Hardware: NXP JN5189
RCP Firmware - Repository: https://github.com/openthread/ot-nxp.git
Branch: main
Commit: 70a5b2dd33ff30e938aac7556a84804a84ce05a9

Host OS: Linux (OpenWRT)
Thread version: 1.4.0

Commissioner: ChipTool APK (Android)

End Device: Nanoleaf Thread Device

For Compilation Purpose I've applied the below patches on top of the vanilla ot-nxp repo

ot_nxp_applied_changes_patch.txt

Reproduction Steps
Commission Nanoleaf device onto the Thread network via OTBR.
Use ChipTool APK to send rapid commands (e.g., Toggle command in a loop with minimal delay).
Observe otbr-agent logs for framing errors and eventual timeout crash.

NxpJN5189_RCP_Debug_Log.log

[jwhui]

This issue seems specific to the JN5189. I would reach out directly to the vendor for support or try using different RCP hardware.

[VVG1997]

Thank you for your reply.

Could you point to any specific details that suggests this is a problem related to the JN5189? I want to understand if this is related to known limitations, differences with other hardware versions, or, if there are previous reports. This will help me in either an additional debugging process, or report this to the vendor.

[jwhui]

I am not aware of many using JN5189 as an RCP in their product designs. There are many reasons why an RCP could become unresponsive.

[VVG1997]

Is there any provision for retransmitting a corrupted frame back to RCP?

[jwhui]

No. A properly implemented serial bus (UART, SPI, I2C) should be very reliable with communication errors exceedingly rare.