«STM32F103CB module blinking red/rebooting on v1.3.4.52 with Taranis X9D Plus»

[ThePhantom05]

Hello Pascal
,I am facing a serial sync / boot loop issue with the latest custom compilation of the Multiprotocol firmware (v1.3.4.52) on my iRangeX IRX4 module (equipped with the STM32F103CBT6 MCU).
When I flash the custom v1.3.4.52 build, the module successfully compiles (using around 71% of flash memory) and writes without any errors via Flash Multi. However, as soon as I plug it into my transmitter and select any protocol (e.g., FlySky/Standard), the module goes into a continuous boot loop and blinks red constantly, indicating a lack of serial synchronization with the radio.
Interestingly, if I flash the stable official release mm-stm-serial-aetr-air-v1.3.4.31.bin connection works flawlessly, and the status LED stays solid.
The issue only appears on the newer .52 source code commits.
My Setup:
Transmitter: FrSky Taranis X9D Plus (classic 3-button layout)
Operating System: EdgeTX v2.9.4
Module MCU: STM32F103CBT6 (128KB)
My exact Flash Multi compilation log:
Multi Firmware Version: 1.3.4.52 (STM32F1)
Firmware Target: STM32F103CB (128KB)
Expected Channel Order: AETR
Telemetry Type: OpenTX or erSkyTx (MULTI_TELEMETRY)
Invert Telemetry Enabled: True
Flash from Radio Enabled: True
Bootloader Enabled: True
USB Serial Support: False
Serial Debug Enabled: False
I have verified that all required protocols are properly uncommented. I also tried commenting out #define INVERT_TELEMETRY_TX and performing a full "Erase Flash" before writing, but the constant red blinking on v1.3.4.52 persists.
Could you please check if there is a known serial timing or interrupt conflict introduced in the recent commits for the STM32F103CB targets operating in Serial mode with older Taranis telemetry boards?
Thank you for your amazing work on this project!

[ThePhantom05]

P.S. IMPORTANT DIAGNOSTIC UPDATE:
I have carried out an extensive troubleshooting isolation test using a clean environment to determine the exact cause of the boot loop.

1. I set up a pristine, fully isolated portable environment using Arduino IDE 1.8.19 on Windows 11.
2. I successfully downgraded and installed the stable Multi-Module STM32 Board definitions v1.2.2 and the corresponding GCC toolchain.
3. I used the official v1.3.4.31 source code and highly optimized my Config.h by disabling all unused surface, telemetry, and low-power protocols. This reduced resource utilization drastically:
   • Sketch uses 78,924 bytes (65% of flash)
   • Global variables use 3,880 bytes (18% of dynamic memory)
4. After compiling this clean build locally via board v1.2.2 and flashing via Flash Multi, the module still ends up in a continuous boot-loop (steadily blinking red LED) when plugged into my Taranis X9D Plus running EdgeTX 2.9.4.
5. However, the pre-compiled factory binary "mm-stm-serial-aetr-air-v1.3.4.31.bin" flashes and runs absolutely flawlessly with a solid red LED on the exact same hardware setup.

CONCLUSION: The issue is NOT toolchain bloat, hardware failure, or RAM exhaustion (since global variables are down to 18%). There is a definitive code regression or compilation parameter mismatch that breaks microsecond serial telemetry inverter timings for the classic Taranis X9D Plus when compiled locally. Pascal, please look into how the local compiler optimizes the serial synchronization routines compared to your factory deployment pipeline.

[ThePhantom05]

Here is my actual _Config.h from the v1.3.4.52 source code (renamed to .txt). I have highly optimized it by disabling all unused surface, telemetry, and low-power protocols in accordance with my previous v1.3.4.31 tests.

Resource utilization is extremely safe:

• Flash: ~65%
• RAM (Global variables): 3,880 bytes (18%)

Even with this lightweight configuration and using the stable Multi-Module STM32 Board v1.2.2 core on a clean portable Arduino IDE 1.8.19 environment, any locally compiled binary still results in a continuous boot loop (steadily blinking red LED) on the classic Taranis X9D Plus hardware inverter (EdgeTX 2.9.4). Meanwhile, your pre-compiled factory .bin files for v1.3.4.31 run flawlessly on the exact same module.

Please check the attached file. It includes the new protocols I need. There is a definitive code regression or compilation parameter mismatch affecting local toolchains for classic Taranis hardware sync.

_Config.txt

[ThePhantom05]

FINAL UPDATE: The issue is 100% SOLVED!

Thanks to the incredible support from alm_nl and Mike Blandford on RC Groups, we isolated the root cause to a local compiler toolchain parameter mismatch. My custom _Config.h optimized layout is absolutely correct.

When compiled using the correct modern xPack GCC ARM toolchain (v8.3.1 or v9.2.1), the resulting v1.3.4.52 binary flashes perfectly, successfully initializes the serial connection, and the status LED stays SOLID RED on my classic FrSky Taranis X9D Plus inverter under EdgeTX 2.9.4.

The legacy 2014-era GCC 4.8.3 compiler from the standard board manager was introducing aggressive instruction jitter that ruined the microsecond telemetry sync phase on discrete transistor hardware.

The iRangeX module is now fully operational with all my JJRC models and my UDI001 Venom boat. Huge thanks to everyone involved for this fantastic deep dive diagnostic trip. Closing this ticket!

[ThePhantom05]

RE-OPENING THE INVESTIGATION: Critical hardware discovery found!

Pascal, please re-open this ticket. We found a definitive hardware symptom that points directly to a regression in the serial/USART sync code in the v1.3.4.52 branch.

Testing on my clean, verified setup reveals this:

1. In PPM Mode (Rotary switch set to 1, External RF -> PPM): The iRangeX module initializes flawlessly, status LED stays SOLID RED, and all channels are responsive. The module is fully alive.
2. In MULTI Mode (Rotary switch set to 0, External RF -> MULTI): The module instantly drops into an infinite bootloop and flashes red, regardless of whether I use FlySky, JJRC, or any other protocol.

This happens on both local GCC 8.3.1 compilations and the exact binary pre-compiled by alm_nl. However, your official factory next-gen v1.3.4.31 AIR binary still works perfectly in MULTI mode on this identical hardware.

This means that the newer v1.3.4.52 branch contains a USART/DMA code rewrite that breaks the microsecond packet synchronization phase specifically for the discrete transistor-based telemetry inverter inside the classic FrSky Taranis X9D Plus hardware.

Could you please check if the serial bit-bashed skew or DMA priority handling was changed between v1.3.4.31 and v1.3.4.52? We have confirmed that the issue is isolated to the MULTI serial negotiation phase on classic hardware.

[ThePhantom05]

UPDATE: Important telemetry inverter hardware discovery!

We have isolated the root cause with Mike Blandford on RC Groups. The issue is strictly caused by a USART/DMA serial synchronization regression introduced in the newer source code branch (v1.3.4.52).

The module works perfectly under EdgeTX 2.9.4 with the factory v1.3.4.31 AIR binary. However, any newer custom compilation drops the module into an infinite bootloop (blinking red LED) when EdgeTX initializes the digital MULTI serial mode (rotary switch at 0).

Interestingly, if we change the radio menu setting to analog PPM (with the physical rotary switch still at 0), the module instantly picks up the analog signal, and the status LED turns SOLID RED. A complete "cold boot" test also failed to fix MULTI mode, which completely rules out any on-the-fly mode switching conflicts.

Mike Blandford noted that the digital MULTI serial phase train generated by EdgeTX on the classic X9D+ hardware requires specific output skew/delay compensation to account for the classic discrete transistor telemetry inverter latency. The newer branch code seems to break this microsecond timing window, while the old v1.3.4.31 code tolerated the transistor delay perfectly.

Could you please review if this USART sync phase regression can be patched or adjusted in the main repository to support classic FrSky hardware owners?

Here is the direct link to our ongoing technical discussion with Mike Blandford on RC Groups:
https://www.rcgroups.com/forums/showthread.php?2165676-DIY-Multiprotocol-TX-Module/page1771#post54954967

@benlye @pascallanger

UPDATE: Important telemetry inverter hardware discovery!
We have isolated the root cause with Mike Blandford on RC Groups...

[ThePhantom05]

@benlye, here is my exact custom config file layout that I am trying to build. I want to combine my classic aviation models with specific surface/boat protocols.

Could you please use this exact config to compile a test binary of the v1.3.4.52 branch for me on your sterile build server? This will completely rule out any local compiler anomalies on my PC.

Config.txt

[ThePhantom05]

Hi Pascal and Ben,Following Mike's test on RC Groups, I commented out #define ENABLE_PPM and completely isolated the PPM banks array inside _Config.h using #ifdef ENABLE_PPM. Then I compiled the v1.3.4.52 source code locally using xPack GCC 8.3.1.The compilation was successful, and after flashing this custom binary via Flash Multi, the infinite bootloop on my classic Taranis X9D Plus is completely gone! The status LED stays solid, and all digital MULTI protocols are working flawlessly now.This 100% confirms the critical interrupt/timer regression between the new USART logic and PPM code on legacy transistor-based inverter hardware. Thank you all for the incredible teamwork! The issue is fully resolved for me.