target: add CIPHERWINGF4 (STM32F405)

[jeevesh326]

User description

🧩 Summary

Adds support for Cipherwing F4 — a custom STM32F405 flight-controller board derived from Omnibus F4, with a fully customized UART, ADC, and motor-timer map.

⚙️ Board Information

Item | Value -- | -- Board name | Cipherwing F4 Target ID | CIPHERWINGF4 (CYF4) MCU | STM32F405RG Firmware | INAV 8.0.1 Base | Omnibus F4 MAX PWM Outputs | 8 LED Strip | PB6 (TIM4_CH1) Status LED | PB5 Beeper | PB4 (active low) VBAT ADC | PC2 RSSI ADC | PC1

🧱 Folder Structure

src/main/target/CIPHERWINGF4/
 ├── CMakeLists.txt
 ├── target.c
 └── target.h

📦 Build Information

FLASH: 617 156 / 896 KB (67.3 %)
RAM:   110 832 / 128 KB (84.6 %)
CCM:    23 732 / 64 KB (36.2 %)
Artifacts: inav_8.0.1_CIPHERWINGF4.hex / .bin

✅ Hardware Verification

• IMU detected (SPI1)

• OSD & Blackbox operational (SPI3)

• VBAT / RSSI ADC inputs functional

• 8 motor outputs verified (PWM + DSHOT)

• LED strip on PB6 and beeper on PB4 tested

• UART mapping validated (CRSF on UART1)

🧾 Notes

• Only one IMU should be active at a time (shared SPI1 bus).

• UART5 TX left unassigned to avoid conflict with SPI3 MOSI.

• Current sensor input removed — VBAT and RSSI only.

🧰 Files Added

src/main/target/CIPHERWINGF4/CMakeLists.txt
src/main/target/CIPHERWINGF4/target.c
src/main/target/CIPHERWINGF4/target.h

---

PR Type

Enhancement

---

Description

• Adds support for Cipherwing F4 STM32F405 flight controller board

• Implements custom UART, ADC, and motor-timer configuration

• Defines 8-motor PWM outputs with LED strip support

• Configures IMU, OSD, blackbox flash, and sensor interfaces

---

Diagram Walkthrough

flowchart LR
  A["CIPHERWINGF4<br/>STM32F405RG"] --> B["8 Motor Outputs<br/>TIM1/3/4/8/12"]
  A --> C["LED Strip<br/>TIM4 CH1 PB6"]
  A --> D["Sensors<br/>IMU/MAG/BARO"]
  A --> E["Interfaces<br/>6 UARTs SPI I2C"]
  A --> F["Storage<br/>OSD MAX7456<br/>Blackbox M25P16"]

Loading

File Walkthrough

Relevant files

Configuration changes

target.h Board configuration and peripheral definitions                      src/main/target/CIPHERWINGF4/target.h Defines board identifier "CYF4" and USB product string Configures 6 UART ports with custom pin mappings Sets up I2C1 for external sensors (MAG, BARO) Defines SPI buses for OSD (MAX7456) and blackbox flash (M25P16) Maps ADC channels for VBAT (PC2) and RSSI (PC1) Enables LED strip on PB6 and configures 8-motor support with DSHOT Specifies IMU options (MPU6000, ICM20689, ICM42605) on SPI1 +161/-0  target.c Motor and LED timer hardware mapping                                          src/main/target/CIPHERWINGF4/target.c Defines timer hardware mapping for 8 motor outputs across TIM1/3/4/8/12 Maps motors M1-M8 to specific timer channels and GPIO pins Configures LED strip output on TIM4 CH1 (PB6) Uses TIM_USE_OUTPUT_AUTO for motor PWM and TIM_USE_LED for LED strip +27/-0    CMakeLists.txt Build configuration for STM32F405                                                src/main/target/CIPHERWINGF4/CMakeLists.txt Specifies STM32F405XG MCU target for CIPHERWINGF4 build configuration +4/-0

---

[qodo-merge-pro]

PR Compliance Guide 🔍

All compliance sections have been disabled in the configurations.

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Correct an invalid UART pin assignment Correct the UART5_TX_PIN assignment from the invalid PC13 to the correct PC12 to ensure UART5 functionality on the STM32F405 MCU. src/main/target/CIPHERWINGF4/target.h [85-87] #define USE_UART5 #define UART5_RX_PIN PD2 -#define UART5_TX_PIN PC13 +#define UART5_TX_PIN PC12 Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies that PC13 is an invalid pin for UART5_TX on an STM32F405 MCU and proposes the correct pin PC12, fixing a non-functional peripheral in the target definition.	High
	Reassign LED pin to resolve conflict Reassign LED0 from PB5 to PC13 to free up PB5 for SPI3_MOSI_PIN, resolving a hardware pin conflict. src/main/target/CIPHERWINGF4/target.h [18] -#define LED0 PB5 +#define LED0 PC13 Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion provides a valid solution to a complex pin conflict involving UART5, SPI3, and LED0 by correctly reassigning LED0 to the now-free PC13, enabling other necessary pin changes.	Medium
More

[MrD-RC]

Please note that new targets must follow the INAV New Hardware Policy

Have you been in contact with any developers?

[jeevesh326]

Thanks for the automated suggestions 🙏
For this board, UART5 is intentionally RX-only — it’s used exclusively for SBUS/CRSF input.
There is no TX pad on the PCB, and assigning one would create a hardware conflict (PC12 is already used for SPI3 MOSI for OSD + Flash).
Therefore, UART5_TX is left as a dummy / unconnected assignment to maintain target consistency, and this is the expected behavior for the Cipherwing F4.

No change required — design verified and working as intended ✅

[jeevesh326]

Please note that new targets must follow the INAV New Hardware Policy

Have you been in contact with any developers?

Thanks for the reminder about the INAV New Hardware Policy 🙏

The Cipherwing F4 (STM32F405) is part of an early testing phase for our upcoming product line.
It’s not an official or mass-produced board yet — this PR is mainly to start early firmware validation and bring-up testing within INAV.

Key points:
• The hardware is based on Omnibus F4 architecture, with a custom UART, ADC, and motor-timer map.
• The board fully meets INAV’s technical requirements (IMU, baro, I²C, 512 KB+ flash, 128 KB RAM, etc.).
• UART5 is RX-only by design; there is no TX pad on the PCB (PC12 is used by SPI3 MOSI for OSD + Flash).
• All major peripherals (IMU, OSD, Flash, VBAT/RSSI, LEDs, buzzer, and motor outputs) are functional and tested.

This target is intended for internal and community testing only, not as an official commercial release at this stage.

Once the board reaches its stable revision, I’ll be happy to coordinate with INAV maintainers to provide documentation, samples, and request official inclusion.

Please proceed treating this PR as an unofficial / prototype target submission for evaluation and early feedback.

[MrD-RC]

Thanks for the automated suggestions 🙏 For this board, UART5 is intentionally RX-only — it’s used exclusively for SBUS/CRSF input. There is no TX pad on the PCB, and assigning one would create a hardware conflict (PC12 is already used for SPI3 MOSI for OSD + Flash). Therefore, UART5_TX is left as a dummy / unconnected assignment to maintain target consistency, and this is the expected behavior for the Cipherwing F4.

No change required — design verified and working as intended ✅

IMHO, the RX UART should be a full UART. The only SBUS needs only the RX UART pad. All other protocols, which are more widely used, use RX and TX. The only thing I can think of where only a UART receiver pad is needed is ESC telemetry from a BLHeli32 ESC.

I really don't think the Omnibus F4 is a good FC to base a new FC on. It was limited when it was release years ago. It is even more limited now. UART wise, it's only half a UART better than an F411 based FC. Modern F405 based FCs have 4 or 5 full UARTs broken out. It would be better to start from the ground up with the design or look at more modern flight controllers for inspiration.

[jeevesh326]

Thanks for the automated suggestions 🙏 For this board, UART5 is intentionally RX-only — it’s used exclusively for SBUS/CRSF input. There is no TX pad on the PCB, and assigning one would create a hardware conflict (PC12 is already used for SPI3 MOSI for OSD + Flash). Therefore, UART5_TX is left as a dummy / unconnected assignment to maintain target consistency, and this is the expected behavior for the Cipherwing F4.

No change required — design verified and working as intended ✅

IMHO, the RX UART should be a full UART. The only SBUS needs only the RX UART pad. All other protocols, which are more widely used, use RX and TX. The only thing I can think of where only a UART receiver pad is needed is ESC telemetry from a BLHeli32 ESC.

I really don't think the Omnibus F4 is a good FC to base a new FC on. It was limited when it was release years ago. It is even more limited now. UART wise, it's only half a UART better than an F411 based FC. Modern F405 based FCs have 4 or 5 full UARTs broken out. It would be better to start from the ground up with the design or look at more modern flight controllers for inspiration.

About the RX-only UART:
I agree that most modern receiver protocols (CRSF/ELRS, MSP, telemetry) need full duplex. On this board those live on full UARTs. Only UART5 is intentionally RX-only for cases like SBUS (or optional BLHeli32 ESC telem). The board exposes multiple full UARTs on pads:
• UART1 (RX/TX) – intended for CRSF/ELRS
• UART2 (RX/TX)
• UART3 (RX/TX)
• UART4 (RX/TX)
• UART6 (RX/TX)
• UART5 – RX-only by design (no TX pad; PC12 is SPI3 MOSI for OSD/Flash)

So the target meets the policy requirement of ≥3 full UARTs; RX-only UART5 is just an extra dedicated SBUS/telemetry input.

About basing on Omnibus F4:
Totally hear you—Omnibus F4 is dated. I reused its general layout for a prototype/bring-up because parts and reference designs are easy to source, but the pinout is fully customized (8 PWM, SPI3 OSD+Flash, I²C sensors, VBAT/RSSI, etc.). This PR is explicitly for early validation / community testing, not a production endorsement.

For the next hardware rev, I plan to:
• keep 4–5 full UARTs broken out (minimum),
• consider a more modern layout (or F7) for better IO headroom,
• submit updated docs/schematics alongside samples if we pursue official inclusion.

If preferred, I’m happy to keep this as an unofficial/prototype target (e.g., CIPHERWINGF4-DEV) while we iterate. Thanks again for the guidance—open to any specific changes you’d like on the target to align better with INAV expectations.

[MrD-RC]

OK, that's sounding pretty cool. It sounds like it is much different to the Omnibus F4 at this stage. So I would probably remove that association, as it just raises red flags. I immediately thought 2.5 UARTs and issues using UART 3 due to the I2C integration.

As this is still in development, and doesn't yet meet the new hardware policy (due to INAV developers not having test samples). I'm going to add the do not merge label. But this is just to put that on hold while the development is taking place. So don't see it as bad. It's just temporary while you guys carry on working on the FC 👍🏻

[jeevesh326]

OK, that's sounding pretty cool. It sounds like it is much different to the Omnibus F4 at this stage. So I would probably remove that association, as it just raises red flags. I immediately thought 2.5 UARTs and issues using UART 3 due to the I2C integration.

As this is still in development, and doesn't yet meet the new hardware policy (due to INAV developers not having test samples). I'm going to add the do not merge label. But this is just to put that on hold while the development is taking place. So don't see it as bad. It's just temporary while you guys carry on working on the FC 👍🏻

Thanks so much for the clarification and for keeping it open 🙏
Totally understand about the do not merge label — that makes complete sense while the hardware is still in its prototype stage.

I’ll remove the Omnibus F4 references in the next update and make the documentation clearly describe it as a stand-alone Cipherwing F4 design (since, as you said, the layout and peripherals have diverged significantly).

Over the next iteration, I’ll:
• Add a proper board doc (docs/boards/CIPHERWINGF4.md) with the final pinout table and PCB photos
• Prepare to share hardware samples with INAV devs once the test batch is finalized
• Keep the PR updated for early firmware testing and community feedback

Thanks again for the feedback and for keeping the PR active — really appreciate the guidance! 🙌

[jeevesh326]

merge label. But this is just to put that on hold

@MrD-RC Can you please verify the pcb
New version

Older version

[MrD-RC]

I don't know what you mean by verify the PCB. I can look at it and offer some advice on the layout. But not much more than that. It certainly couldn't be merged just by looking at the PCB.

• What are the dimensions?
• Who is the target users (fixed-wing, multi-rotor, or general purpose)?

[jeevesh326]

I don't know what you mean by verify the PCB. I can look at it and offer some advice on the layout. But not much more than that. It certainly couldn't be merged just by looking at the PCB.

• What are the dimensions?
• Who is the target users (fixed-wing, multi-rotor, or general purpose)?

Thanks for reviewing!
The board dimensions are 50 mm × 42 mm.
It’s designed as a general-purpose flight controller, suitable for both fixed-wing and multirotor platforms.

[jeevesh326]

you can check the user manual for all the details @MrD-RC
end_manual.pdf

[MrD-RC]

My first thoughts are that it is pretty large. For a standard board like this, you should be aiming for around 36mm square. I'd also aim to get all the pads that the pilots are soldering to around the outside edge in useful groups. So for all UARTs also have 5v and gnd, plus with one UART have I2C pads too. I'd go back to using through hole pads too. Then header pins or direct soldering can be used. I see there is one ADC broken out (RSSI). But it may be worth breaking out another. There is no current sensor on this FC, so an external one may be wanted. TBH, most RC links these day provide RSSI over the UART. So I would default the existing ADC to a different function. Perhaps a voltage ADC input, as this board can only handle up to 3S.

You could save a lot of space by removing the power and grounds for the servo outputs. I see this is a design taken over from Omnibus. The problem is that they were never good, as there was no separate 5V servo power rail that had enough current available. It was also only 5v, whereas most servos benefit from using 6v. Anyway, they always needed an external DC-DC to power the servos to be reliable. I see your board only has a 2A 5V rail, which powers all 5v peripherals. This really isn't enough to power servos too. For servos alone, you should be looking at a minimum of 4A when you have 6 outputs available.

Please don't take this as bad. I'm trying to be constructive.

[sensei-hacker]

Mr D. made some good points. The servo power rail was mentioned.

The Omnibus had three Schottky diodes on the servo rail, so it could be powered from the onboard BEC, from an external BEC, or USB. With no jumpers needed. I liked that option. It could run a couple small servos from the onboard BEC, or you could plug in an ESC with a BEC, and could test servos with just USB plugged in.