RP4-TD UART-bridge setup enters failsafe (100 ms red blink) and never reconnects

[ddosoff]

Good day, OlliW 👋

First of all, thank you for your tremendous work on mLRS!
What I’m doing

Two RadioMaster RP4-TD 2.4 GHz boards

    TX side – flashed with tx-radiomaster-rp4td-2400-sik-telem

    RX side – flashed with rx-radiomaster-rp4td-2400

Using them purely as a UART bridge (simple “pinger” app on the serial ports confirms the link).

Issue

Link works flawlessly at short range.

When I walk far enough for the RX to lose the signal, it correctly enters failsafe and the red LED begins flashing very rapidly (~100 ms period).

After that the RX never regains the link, even when I move back into range; only a rx power-cycle helps.

Expected behaviour

RX should automatically exit failsafe and reconnect to the TX once the signal returns.
Actual behaviour

Remains in failsafe indefinitely.

LED keeps flashing at ~10 Hz.

No data are forwarded over UART until the RX is rebooted.

Environment

mLRS commit: … <– (current master, cloned 2025-08-03)

Could you please point me to the proper fix or advise how to make the RX re-enter LISTEN → SYNC → CONNECTED automatically?

Thank you! 🙏

[olliw42]

this does not look like a normal failsafe

it looks to me like it goes into one of the failure modes
you say it blinks at 10 Hz. Can you pleae describe in more detail the blink pattern of the leds. For both rx and tx (they can be different)

we could need also more info, like what mode, what frequency band
it recovers only when the rx is power cylcled, or does it also recover when the tx is power cylced?
are you using it in combination with some other RF system, if so which?

@jlpoltrack @brad112358 @tmcadam I suspect an issue with that one of them goes into a FAIL. Given the past, a luikely reason could be on the tx side with some timing. Since I'm not so much on the esp side of things, your input would be valuable :)

[ddosoff]

Today I ran extensive tests with both the original RP4TD and a Chinese clone to rule out hardware issues. The problem shows up only on the receiver side.

Each time, after a series of weak-signal disconnects, the receiver switches to a rapid red-blinking mode. The number of dropouts needed varies—sometimes more than ten, sometimes just two—but the behavior is consistent and reproducible, even if it’s not always easy to trigger.

Here’s a short clip of the red blinking: https://www.youtube.com/shorts/GPttrzWk6cc

[jlpoltrack]

Each time, after a series of weak-signal disconnects, the receiver switches to a rapid red-blinking mode. The number of dropouts needed varies—sometimes more than ten, sometimes just two—but the behavior is consistent and reproducible, even if it’s not always easy to trigger.

This to me sounds like you are also potentially dealing with heavy interference and are therefore entering an RF fail state, given that you are building from main, you can try commenting out these lines which will avoid these fail states and should allow the link to avoid getting stuck in a fail state:

https://github.com/olliw42/mLRS/blob/main/mLRS/CommonRx/mlrs-rx.cpp#L13-L14
https://github.com/olliw42/mLRS/blob/main/mLRS/CommonTx/mlrs-tx.cpp#L13-L14

[ddosoff]

I enabled debug and got this log before entering fail state:

[RAW IN]: fail a0 03
[RAW IN]: 1!2!t2<
[RAW IN]: >fail
[RAW IN]: fail a0 04
[RAW IN]: 1!fail
[RAW IN]: fail a1 03
[RAW IN]: 2!t2<
[RAW IN]: >1!fail
[RAW IN]: fail a1 03
[RAW IN]: 2!t2<
[RAW IN]: >fail
[RAW IN]: fail a0 04
[RAW IN]: 1!fail
[RAW IN]: fail a1 04
[RAW IN]: 2!t2<
[RAW IN]: >1!2!t2<
[RAW IN]: >t2<
[RAW IN]: >1!2!t2<
[RAW IN]: >t2<
[RAW IN]: >1!2!t2<
[RAW IN]: >fail
[RAW IN]: fail a0 04
[RAW IN]: 1!fail
[RAW IN]: fail a1 04
[RAW IN]: 2!t2<
[RAW IN]: >fail
[RAW IN]: fail a1 01
[RAW IN]: do_receive() CHECK_ERROR_SYNCWORD
[RAW IN]: do_receive() CHECK_ERROR_SYNCWORD
[RAW IN]: do_receive() CHECK_ERROR_SYNCWORD
[RAW IN]: do_receive() CHECK_ERROR_SYNCWORD
[RAW IN]: do_receive() CHECK_ERROR_SYNCWORD
[RAW IN]: do_receive() CHECK_ERROR_SYNCWORD

Also button not works any more. Only full reset helps.

[ddosoff]

Commenting out this lines helps with fail state hung up:

https://github.com/olliw42/mLRS/blob/main/mLRS/CommonRx/mlrs-rx.cpp#L13-L14
https://github.com/olliw42/mLRS/blob/main/mLRS/CommonTx/mlrs-tx.cpp#L13-L14

But RX still reboots some time on weak signals. I see ESP booting message on the UART.

[jlpoltrack]

But RX still reboots some time on weak signals. I see ESP booting message on the UART.

Can you try and capture the crash + boot message from the ESP? The crash message should be right before the boot message.

[ddosoff]

Reboot trace:

RAW IN: fail a1 02
RAW IN: 2!t2<
RAW IN: >1!2!t2<
RAW IN: >t2<
RAW IN: >2!t2<
RAW IN: >2!t2<
RAW IN: >
RAW IN: Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1).
RAW IN: Core 1 register dump:
RAW IN: PC : 0x400de3ad PS : 0x00060535 A0 : 0x800d2845 A1 : 0x3ffbf20c
RAW IN: A2 : 0x00000001 A3 : 0x3ffbf27b A4 : 0x3ffc3678 A5 : 0x00000001
RAW IN: A6 : 0x3ff65000 A7 : 0xffffffff A8 : 0x00040000 A9 : 0x00000001
RAW IN: A10 : 0x3ffbf27f A11 : 0x00000015 A12 : 0x00000001 A13 : 0x00000001
RAW IN: A14 : 0x3ffc379c A15 : 0x00000001 SAR : 0x00000007 EXCCAUSE: 0x00000006
RAW IN: EXCVADDR: 0x00000000 LBEG : 0x400de388 LEND : 0x400de39b LCOUNT : 0x00000000
RAW IN: Core 1 was running in ISR context:
RAW IN: EPC1 : 0x400e96f3 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x00000000
RAW IN: Backtrace: 0x400de3aa:0x3ffbf20c |<-CORRUPTED
RAW IN: Core 0 register dump:
RAW IN: PC : 0x4008b85b PS : 0x00060035 A0 : 0x80081277 A1 : 0x3ffbea9c
RAW IN: A2 : 0x3ffbdb94 A3 : 0xffffffff A4 : 0x00006666 A5 : 0x00060023
RAW IN: A6 : 0x00060023 A7 : 0x0000cdcd A8 : 0x00000001 A9 : 0xffffffff
RAW IN: A10 : 0x00060023 A11 : 0x3ffc3b4c A12 : 0x0066cdf3 A13 : 0x00060023
RAW IN: A14 : 0x007bdb94 A15 : 0x003fffff SAR : 0x00000020 EXCCAUSE: 0x00000006
RAW IN: EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
RAW IN: Backtrace: 0x4008b858:0x3ffbea9c |<-CORRUPTED
RAW IN: ELF file SHA256: 1804d49ba955295b
RAW IN: Rebooting...
RAW IN: ets Jun 8 2016 00:22:57
RAW IN: rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
RAW IN: configsip: 188777542, SPIWP:0xee
RAW IN: clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
RAW IN: mode:DIO, clock div:1
RAW IN: load:0x3fff0030,len:1344
RAW IN: load:0x40078000,len:13964
RAW IN: load:0x40080400,len:3600
RAW IN: entry 0x400805f0
RAW IN: E (8) gpio: gpio_isr_handler_remove(482): GPIO isr service is not installed, call gpio_install_isr_service() first
RAW IN: E (364) gpio: gpio_isr_handler_remove(482): GPIO isr service is not installed, call gpio_install_isr_service() first
RAW IN: Hello
RAW IN: >
RAW IN: 2!t2<
RAW IN: >1!2!t2<

One more:

RAW IN: fail a1 04
RAW IN: 2!t1<
RAW IN: >fail
RAW IN: fail a1 03
RAW IN: 2!t1<
RAW IN: >1!t1<
RAW IN: >t1<
RAW IN: >
RAW IN: Guru Meditation Error: Core 1 panic'ed (Interrupt wdt timeout on CPU1).
RAW IN: Core 1 register dump:
RAW IN: PC : 0x400de239 PS : 0x00060335 A0 : 0x800d280d A1 : 0x3ffbf1ec
RAW IN: A2 : 0x00000001 A3 : 0x3ffbf25b A4 : 0x3ffc3658 A5 : 0x00000001
RAW IN: A6 : 0x3ff65000 A7 : 0xffffffff A8 : 0x00040000 A9 : 0x00000001
RAW IN: A10 : 0x3ffbf25f A11 : 0x00000015 A12 : 0x00000001 A13 : 0x00000001
RAW IN: A14 : 0x3ffb2193 A15 : 0x00000001 SAR : 0x00000007 EXCCAUSE: 0x00000006
RAW IN: EXCVADDR: 0x00000000 LBEG : 0x400de214 LEND : 0x400de227 LCOUNT : 0x00000000
RAW IN: Core 1 was running in ISR context:
RAW IN: EPC1 : 0x400e957f EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x00000000
RAW IN: Backtrace: 0x400de236:0x3ffbf1ec |<-CORRUPTED
RAW IN: Core 0 register dump:
RAW IN: PC : 0x4008b9c4 PS : 0x00060035 A0 : 0x800812d6 A1 : 0x3ffbea9c
RAW IN: A2 : 0x3ffbdb74 A3 : 0x3ffc3b2c A4 : 0x001a515d A5 : 0x00060023
RAW IN: A6 : 0x00060023 A7 : 0x00000001 A8 : 0x00000000 A9 : 0x0000cdcd
RAW IN: A10 : 0x00060023 A11 : 0x00000001 A12 : 0x00000000 A13 : 0x00000001
RAW IN: A14 : 0x007bdb74 A15 : 0x003fffff SAR : 0x00000020 EXCCAUSE: 0x00000006
RAW IN: EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
RAW IN: Backtrace: 0x4008b9c1:0x3ffbea9c |<-CORRUPTED
RAW IN: ELF file SHA256: 1dd628f78a248f48
RAW IN: Rebooting...
RAW IN: ets Jun 8 2016 00:22:57
RAW IN: rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
RAW IN: configsip: 188777542, SPIWP:0xee
RAW IN: clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
RAW IN: mode:DIO, clock div:1
RAW IN: load:0x3fff0030,len:1344
RAW IN: load:0x40078000,len:13964
RAW IN: load:0x40080400,len:3600
RAW IN: entry 0x400805f0
RAW IN:
RAW IN: E (364) gpio: gpio_install_isr_service(450): GPIO isr service already installed
RAW IN: Hello
RAW IN: E (1078) gpio: gpio_install_isr_service(450): GPIO isr service already installed
RAW IN: >

[jlpoltrack]

Thanks for sharing - so it says an interrupt on Core 1 is timing out. Hmm, there are only 2 interrupts on Core 1 - the Sx chipset interrupt and the 1 millisecond timer. I suppose I would be inclined to think this is more likely something around the Sx chipset since this seems to only appear in low LQ conditions.

Could you share:

• How you are able to reproduce? I quickly tried to recreate a low LQ condition and then drop the link entirely by blocking the antenna. I tried this a dozen or so times and never saw a reboot with the link reconnecting. (Hardware is SuperD, so should be similar to an ESP32 + SX128x diversity)
• Do you have an active connection to a flight controller with a a telemetry stream while you are testing?
• Have you made any code modifications? (I don't think so but just to confirm)

[ddosoff]

I am in the UART bridge mode. No flight controller. Just ping + echo via UART.
To reproduce the weak signal you can do this:

No code modifications.

Than just walk away and it will be easy to find bad signal place.