Unstable OpenThread RCP over USB

[Kodiak]

Hoping to have more luck resolving our issue here. Originally we tried on the OpenThread discussions board: https://github.com/orgs/openthread/discussions/11627

We are using the ESP32C6 chip in our custom board which only has USB (

Code: Select all

/dev/ttyACM0

), no UART, and we want to use it as an OpenThread RCP. Luckily, ESP has released support for this not long ago: https://github.com/espressif/esp-idf/co ... 909b002d80

However, we notice that quite often when we plug the device, we get Spinel timeouts that never recover anymore:

Code: Select all

Aug 14 15:32:09 hostname thread-network-manager[4383]: Initializing OpenThread instance on interface wpan0 with radio URL spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800
Aug 14 15:32:17 hostname thread-network-manager[4383]: 49d.17:14:33.264 [W] P-SpinelDrive-: Wait for response timeout
Aug 14 15:32:17 hostname thread-network-manager[4383]: 49d.17:14:35.265 [W] P-SpinelDrive-: Wait for response timeout
Aug 14 15:32:17 hostname thread-network-manager[4383]: 49d.17:14:37.265 [W] P-SpinelDrive-: Wait for response timeout
Aug 14 15:32:17 hostname thread-network-manager[4383]: 49d.17:14:37.265 [C] Platform------: Init() at spinel_driver.cpp:87: Failure
Aug 14 15:32:17 hostname thread-network-manager[4383]: 49d.17:14:39.268 [W] P-SpinelDrive-: Wait for response timeout

This then keeps happening until we re-plug (power cycle) the ESP32C6. We reproduced the same our ESP32C6 DevKit M1

Some more findings that may be relevant:
1. When I take our ESP32C6 DevKit-M1, with the default ot_rcp example but of course configured for RCP over USB, I did this:
I tested with keeping the devkit powered over UART and constantly replugging the USB, it just kept working after way too many replugs. So it seems to stay healthy if the chip/stack doesn't restart, so perhaps a race issue during power on of the ESP firmware
2. The issue seems to reproduce much quicker when the RCP has already hosted a network, and another device has connected to it already. Perhaps having a device wirelessly communicating to the RCP is relevant to reproducing the issue
3. The device always comes back to

Code: Select all

/dev/ttyACM0

, and our OpenThread RCP application always checks for the existence of that device before continuing, so it's not port number related.

I also have a USB pcap of doing many many re-plugs until the issue finally happens, of which I have attached a snippet of the more relevant part:

constant_replugging_working_into_nonworking.zip

(282.42 KiB) Downloaded 28 times