ot-rcp doesn't work on sengled g4

[hlyi]

@jnilo1 I am trying ot-rcp on Sengled G4. However, the api was not available. /var/log/message show the following errors:

Jul  5 05:38:37 (none) daemon.warn keepalive[113]: otbr-agent: exited (code 1), restarting
Jul  5 05:38:37 (none) user.notice : [NOTE]-AGENT---: Backbone interface: eth0
Jul  5 05:39:16 (none) daemon.warn keepalive[113]: otbr-agent: exited (code 1), restarting
Jul  5 05:39:16 (none) user.notice : [NOTE]-AGENT---: Backbone interface: eth0
Jul  5 05:39:55 (none) daemon.warn keepalive[113]: otbr-agent: exited (code 1), restarting
Jul  5 05:39:55 (none) user.notice : [NOTE]-AGENT---: Backbone interface: eth0
Jul  5 05:40:34 (none) daemon.warn keepalive[113]: otbr-agent: exited (code 1), restarting
Jul  5 05:40:34 (none) user.notice : [NOTE]-AGENT---: Backbone interface: eth0
Jul  5 05:41:13 (none) daemon.warn keepalive[113]: otbr-agent: exited (code 1), restarting
Jul  5 05:41:13 (none) user.notice : [NOTE]-AGENT---: Backbone interface: eth0

here is the content of /userdata/etc/radio.conf

FIRMWARE=otrcp
FIRMWARE_BAUD=460800
MODE=otbr
FIRMWARE_FLOW_CTRL=none

Do you know how do I debug this error?

Thanks!

[jnilo1]

Reading of your log

Your host-side configuration is coherent: FIRMWARE_BAUD=460800 is a valid value, and FIRMWARE_FLOW_CTRL=none makes S70otbr start the agent with uart-flow-control=false (no CRTSCTS on the tty — correct for the G4, which has no RTS/CTS wiring; none and sw are handled identically there, since otbr-agent has no XON/XOFF mode of its own).

The pattern in your log — the agent prints its startup banner (Backbone interface: eth0), then exits with code 1, and keepalive restarts it about every 39 seconds — is the classic signature of a silent RCP: otbr-agent launches, tries to initialise the radio over spinel on /dev/ttyS1, gets no response, and gives up. The supervision is working as designed; the question is why the RCP does not answer.

One important context point: there is no pre-built OT-RCP image for the G4 in the repo, and boards/sengled-e39-g8c/board.env carries an explicit caveat — OT-RCP builds for the G4 (MG13, sw flow) but its Thread path has never been functionally tested on G4 hardware. You are the first, so an issue anywhere in that chain is plausible.

Debug steps

1. Capture the actual error. Stop the supervised service and run the agent in the foreground with verbose logging:

   /userdata/etc/init.d/S70otbr stop
   /userdata/usr/bin/otbr-agent -d 5 -I wpan0 -B eth0 \
       "spinel+hdlc+uart:///dev/ttyS1?uart-baudrate=460800&uart-flow-control=false"

   Please post the full output — the exit reason (e.g. an RCP reset timeout vs a version mismatch vs an open error) points at very different culprits.

2. Confirm the firmware provenance and flash path. Which OT-RCP image is on the chip — your own G4 build (BOARD=sengled-e39-g8c, MG13, sw flow)? The lidl prebuilts (26-OT-RCP/firmware/ot-rcp*.gbl) are MG1B builds and will not run on the G4's MG13. And how did you flash it — SWD, or a Gecko bootloader you built yourself? (The repo's Gecko bootloader build is still lidl-only.)

3. Sanity-check the UART link. Re-flash your validated G4 NCP build (Enhancement request: adding BOARD= support to radio FW build enviroment #130) and confirm Zigbee still works. If NCP works and OT-RCP does not, the UART path is fine and the problem is inside the OT-RCP build; if NCP is now broken too, something happened to the link or the chip.

4. Rule out the baud. Build OT-RCP at 115200, flash it, set FIRMWARE_BAUD=115200 in radio.conf, and retry. Your NCP validation ran at 115200, so this puts the UART in a known-good regime. This matters because there is still an open thread from Add flow-control to radio.conf #134 about the SoC→EFR32 TX direction on the G4 — if that direction is unreliable at high baud, spinel initialisation would time out exactly like this.

Also, purely for consistency: if your OT-RCP build came from the G4 board.env (sw flow), set FIRMWARE_FLOW_CTRL=sw rather than none. It changes nothing for otbr-agent today, but it keeps radio.conf describing what is actually on the chip.

Timing note

If this turns out to need a host-side fix, it will ride the v4.0.0 train: we will not publish any new release candidate until issue #99 is definitively closed (rc4 is under field validation).

[hlyi]

@jnilo1 Here is the info based upon your suggestions:

1. I run the command, there is no printout from program at all:

~ # /userdata/usr/bin/otbr-agent -d 7 -I wpan0 -B eth0 --rest-listen-address ::0 --rest-listen-port 8081 --vendor-name Lidl --model-name Silvercrest --data-path /tmp/th
read "spinel+hdlc+uart:///dev/ttyS1?uart-baudrate=460800&uart-flow-control=false"
~ # echo $?
1

2. Yes, I built the binary for MG13: first, I edit boards/sengled-e39-g8c/board.env to set BOARD_UART_FLOW="none", then run BOARD=sengled-e39-g8c ./build_ot_rcp.sh. finally, flash the image with universal-silabs-flasher --device socket://192.168.1.6:8888 flash --firmware ./ot-rcp-460800-sengled-e39-g8c.gbl
3. Yes, NCP still works after reflash NCP firmware.
4. Tried 115200 baud rate as well, the output is the same as 1. i.e. no output from the program at all.

[hlyi]

@jnilo1 I think I found the culprit. the command should not set "uart-flow-control=false". Please see the following code in ot-br-posix/third_party/openthread/repo/src/posix/platform/hdlc_interface.cpp:

        if (aRadioUrl.HasParam("uart-flow-control"))
        {
            tios.c_cflag |= CRTSCTS;
        }

and in ot-br-posix/third_party/openthread/repo/src/lib/url/url.hpp

    bool HasParam(const char *aName) const { return (GetValue(aName) != nullptr); }

Enabling HW flow control is based upon existence of keyword uart-flow-control instead of the value of the keyword. After removing it, HA was able to connect otbr-agent.

Please consider updating S70otbr accordingly.

[hlyi]

I got sw-flow-control working with 115200 baudrate. Here are some patches:

--- S70otbr.orig        2026-07-08 00:22:53.291696817 -0500
+++ S70otbr     2026-07-08 00:22:38.559555117 -0500
@@ -45,11 +45,12 @@
 if [ -f /userdata/etc/radio.conf ]; then
     val=$(grep '^FIRMWARE_FLOW_CTRL=' /userdata/etc/radio.conf | tail -1 | cut -d= -f2)
     case "$val" in
-        none|sw) UART_FC=false ;;
-        hw|"")   UART_FC=true  ;;
+        none) UART_FC="" ;;
+        sw) UART_FC="&uart-sw-flow-control=true" ;;
+        hw|"")   UART_FC="&uart-flow-contorl=true"  ;;
     esac
 fi
-RCP_URL="spinel+hdlc+uart:///dev/ttyS1?uart-baudrate=${FW_BAUD}&uart-flow-control=${UART_FC}"
+RCP_URL="spinel+hdlc+uart:///dev/ttyS1?uart-baudrate=${FW_BAUD}${UART_FC}"
 
 # Network interfaces
 THREAD_IF="wpan0"

and

--- ot-br-posix/third_party/openthread/repo/src/posix/platform/hdlc_interface.cpp.orig  2026-07-07 21:07:47.800834336 -0500
+++ ot-br-posix/third_party/openthread/repo/src/posix/platform/hdlc_interface.cpp       2026-07-07 21:22:37.344310705 -0500
@@ -600,6 +600,11 @@
        {
            tios.c_cflag |= CRTSCTS;
        }
+       else if (aRadioUrl.HasParam("uart-sw-flow-control"))
+        {
+            tios.c_cflag &= ~CRTSCTS;
+            tios.c_iflag |= IXON ;
+        }
        else if (aRadioUrl.HasParam("uart-init-deassert"))
        {
            // When flow control is disabled, deassert DTR and RTS on init

I tried baud rate 460800. otbr-agent just dead silently.

[jnilo1]

Confirmed — excellent find

You are exactly right, and thank you for taking it all the way down to the offending line. Url::HasParam() returns true for any occurrence of the parameter name in the query string, and the radio URL usage text confirms the intended semantics: uart-flow-control — Enable flow control, disabled by default. It is a presence flag, not a boolean. So the uart-flow-control=false that S70otbr emitted for FIRMWARE_FLOW_CTRL=none|sw was actually enabling CRTSCTS — which also corrects what I wrote earlier in this thread, where I called that URL "correct for the G4". It wasn't: on a board with no RTS/CTS wiring, otbr-agent opened the tty with a dead handshake and exited silently, exactly the symptom you reported. That also explains why the foreground run printed nothing.

The fix is in: S70otbr now omits the parameter entirely for none|sw and keeps &uart-flow-control=true for hw (or an absent key), so the Lidl path is byte-for-byte unchanged. I verified in the source that c_cflag is fully rewritten before that block, so omitting the parameter reliably means "no CRTSCTS" — no stale-state edge case. The bug came in with the #134 flow-control split, so it only ever shipped in the v4.0.0 release candidates, never in a GA. Per the release policy stated earlier, the fix rides v4.0.0 (no new RC until issue #99 is definitively closed); in the meantime the one-line change on your box is exactly what you already did — drop the parameter.

One heads-up on your S70otbr patch

In your hw branch there is a typo — uart-flow-contorl=true. Because matching is by name, the misspelled parameter is silently ignored, which would disable hardware flow control on a board that needs it (on the Lidl, that reintroduces the #89 RX-FIFO overrun at 460800). Harmless on your G4 since you run the sw path, but worth fixing if you keep the patch around.

Your IXON patch — and two questions before we decide

Your uart-sw-flow-control addition is technically sound, and we are considering adopting it (correctly spelled) into our otbr-agent build. The supporting details check out in the source: OpenThread's HDLC-lite encoder escapes XON/XOFF inside frames, so raw 0x11/0x13 bytes on the wire are unambiguous flow-control characters — but the decoder writes a raw XOFF straight into the frame body (FCS then fails and the frame is dropped), so without IXON a sw-flow RCP that asserts XOFF corrupts whatever frame is in flight. With IXON the tty layer consumes and obeys them. Two data points would settle how far we take this:

1. Does your patched sw build work at 230400? You confirmed sw at 115200 and dead-silent at 460800; 230400 is the missing point. A sw path capped at 115200 is a very different proposition from one usable at 230400+.
2. Can you confirm the none build worked at 460800? Your second message (HA connecting after removing the parameter) reads like it was the none build still at 460800 — if so, the UART link itself is fine at that speed and the sw@460800 silence is specific to the sw-flow firmware build. That would also connect to the still-open Add flow-control to radio.conf #134 thread about the SoC→EFR32 TX direction on the G4.

With the fix above, sw and none currently behave identically on the host side (no CRTSCTS, no IXON) — which is exactly why your two answers decide whether carrying the IXON patch is worth it, and what baud we document for the G4 OT-RCP path.

[jnilo1]

@hlyi :

A different angle on sw flow: the iostream backend — experimental G4 build attached

Following up on your IXON patch and the #134 discussion about uartdrv's software flow control being "partially supported" (Silabs' wording): there is a place where Silabs finished the job, and today we validated that the OT-RCP can run on it.

The Gecko SDK's OpenThread platform abstraction has two UART backends, selected by project component: uartdrv_usart pulls uartdrv_uart.c (DMA-first — the "partial" sw flow), and iostream_usart pulls iostream_uart.c. The iostream driver (sl_iostream_uart.c — the same one the NCP uses, including your validated G4 NCP sw build) implements XON/XOFF completely: it emits XOFF/XON on RX-buffer watermarks and honors inbound control bytes, per-byte IRQ so the reaction is immediate, no DMA-chunk lag. Swapping backends is a project-file change — no firmware source code involved.

Two things we verified before bringing this to you. The historical objection in our README (iostream corrupts binary streams via LF→CRLF conversion) turned out to be a config toggle, not a property of the driver — SL_IOSTREAM_USART_VCOM_CONVERT_BY_DEFAULT_LF_TO_CRLF 0 and the stream is binary-safe, as the NCP's ASH traffic already proved. And we flashed an iostream-backend OT-RCP (hw flow, 460800) on our Lidl dev gateway today: spinel comes up cleanly, the network forms (leader), and thirty back-to-back spinel operations later the agent had zero restarts and the log zero link errors.

What's in the attached zip

An experimental MG13 / software-flow build of the same thing, for your G4: the modified ot-rcp.slcp, the iostream UART config header (USART0 PA0/PA1, uartFlowControlSoftware, CRLF conversion off), step-by-step build instructions against your rc3 tree, and two prebuilt GBLs (115200 and 460800) in case you'd rather flash first and build later. The prebuilts compile clean here but have never run on real hardware — they only touch the app slot, so recovery is the usual bootloader reflash.

This pairs exactly with your patched otbr-agent: the chip now actually emits XOFF/XON (watermark-driven), and your uart-sw-flow-control → IXON change makes the tty consume and obey them. For the first time both halves of the sw-flow story exist.

What would settle it

1. 115200 first — sanity check against your working uartdrv-sw result. Same behaviour expected, now with real watermark-driven flow control underneath.
2. 460800 — the real question. Your uartdrv-sw build was dead silent there. If the iostream backend comes up at 460800, we have a working software-flow path at full speed on a board with no RTS/CTS — and a strong case for making iostream the OT-RCP default on sw boards in v4.0.0. If it stays dead, that points the finger away from the UART driver and back at the Add flow-control to radio.conf #134 SoC→EFR32 TX question.

Either result is valuable. The two questions from my previous message (uartdrv-sw at 230400, and confirming your none build ran at 460800) remain interesting for the record, but this experiment may leapfrog them.

ot-rcp-iostream-sw-g4-experimental.zip

[hlyi]

@jnilo1
Thanks for catching the typo.
First let me report the findings that based upon your suggestions. the result is from local builds based upon v4.0.0-rc4:

1. none flow control in both otbr-agent and ot-rcp firmware
   a) baudrate = 115200. connection from HA is fine ( no further test)
   b) baudrate = 460800. otbr-agent exits silently.
2. sw flow control enabled in ot-rcp firmware ( I think it still uses DMA driver), patched otbr-agent (ONLY XON enabled, XOFF is NOT enabled)
   a) baudrate = 115200. works with HA (with one matter device paired)
   b) baudrate = 230400, works with HA ( with one matter device paired)
   c) baudrate = 460800, connected to HA, but had issue with paring devices. And kernel log reveals overrun condition.

   kern.warn kernel: [  110.688760] ttyS ttyS1: 1 input overrun(s)
   

   this indicates a few things:
   i) as you mentioned in Add flow-control to radio.conf #134 , dma drivers seems have (ERF32) RX sw flow control enabled, but TX sw flow control disabled, (my otbr-agent patch also matched this assumption, i.e. enabled XON, but disabled XOFF)
   ii) what surprised me is that RTL8196E was not able to handle burst input at 460800 rate.
3. To try iostream uart driver, I think I need to enable XOFF in otbr-agent. I will report back later.

[hlyi]

@jnilo1 with your iostream uart drivers. baudrate = 115200 works as expected. but baudrate =460800 still has the overrun issue:

[  158.783000] ttyS ttyS1: 1 input overrun(s)

[hlyi]

The original issue was resolved. Close this discussion