request 2 Target for Synerduino boards by synersignart · Pull Request #11756 · iNavFlight/inav

synersignart · 2026-08-01T07:30:05Z

@sensei-hacker
here are the request if you can check them out

these are base of the
Weact F405 HSE 8mhz
Weact H743 HSE 25mhz

formerly worked on INAV 9.0.1 however having issues working on INAV 9.1.0

github-actions · 2026-08-01T07:30:14Z

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.
maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

This is an automated suggestion to help route contributions to the appropriate branch.

qodo-code-review · 2026-08-01T07:31:06Z

PR Summary by Qodo

Add SYNERDUINO STM32F405 and H743 board targets (HSE 8/25MHz)

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add two new INAV build targets for Synerduino F405 and H743 boards.
• Define pin mappings for timers/PWM, UARTs, SPI/I2C, ADC, SDIO, and peripherals.
• Register target HSE frequencies (8MHz F405, 25MHz H743) in CMake.

Diagram

graph TD
  A["INAV build (CMake)"] --> B["Target: SYNERDUINOH7"] --> D["Pin/feature defines (target.h)"] --> F["Drivers (SPI/I2C/UART/ADC/Timers)"]
  A --> C["Target: SYNERDUINOSTM_F405"] --> E["Timer map (target.c)"] --> F
  B --> G["Timer map (target.c)"] --> F
  C --> H["Pin/feature defines (target.h)"] --> F

  subgraph Legend
    direction LR
    _cfg["Build/Target config"] ~~~ _map["HW mapping"] ~~~ _drv["Firmware drivers"]
  end

High-Level Assessment

The following are alternative approaches to this PR:

1. Derive from existing upstream targets (Matek H743 / common F405)

➕ Minimizes divergence from upstream pin/bus conventions
➕ Reduces risk of missing required defines for INAV 9.1.x
➕ Easier maintenance across INAV upgrades
➖ May require more careful diffing to isolate what is truly board-specific
➖ Some Synerduino routing may not match reference targets cleanly

2. Start minimal: only required peripherals, enable others incrementally

➕ Simplifies bring-up on 9.1.0 (fewer interacting subsystems)
➕ Makes it easier to isolate failures (e.g., SDIO vs SPI flash vs sensors)
➖ More iterations needed to reach full-feature configuration
➖ Users may expect everything enabled immediately

Recommendation: Current approach (full target.h + timer map + CMake registration) is the right integration point for INAV targets. However, consider trimming/commenting strategy to a minimal, verified baseline first (especially around SPI bus selection and optional peripherals), then enabling additional IMU/OSD/blackbox options once confirmed on INAV 9.1.x. Also ensure naming/defines are internally consistent (e.g., SPI device index vs pin macro names) to avoid subtle 9.1.0 bring-up issues.

Files changed (6) +635 / -0

Enhancement (4) +633 / -0

target.cAdd SYNERDUINOH7 timer/PWM/LED/beeper mapping +56/-0

Add SYNERDUINOH7 timer/PWM/LED/beeper mapping
• Defines timerHardware[] for PWM outputs (S1–S12), WS2812 LED output, and PWM beeper on STM32H7 timers/pins. Exposes timerHardwareCount for the target.
src/main/target/SYNERDUINOH7/target.c

target.hAdd SYNERDUINOH7 board configuration (pins, buses, features) +263/-0

Add SYNERDUINOH7 board configuration (pins, buses, features)
• Introduces SYNERDUINOH7 target identifiers and extensive pin/bus configuration for LEDs, beeper, SPI IMU options, I2C sensors, UARTs, SDIO blackbox logging, ADC channels, PINIO, and LED strip defaults.
src/main/target/SYNERDUINOH7/target.h

target.cAdd SYNERDUINOSTM_F405 timer/PWM/LED/beeper mapping +61/-0

Add SYNERDUINOSTM_F405 timer/PWM/LED/beeper mapping
• Defines timerHardware[] for up to 10 outputs plus WS2812 LED and PWM beeper, using STM32F4 timer definitions and pin mapping. Exposes timerHardwareCount for the target.
src/main/target/SYNERDUINOSTM_F405/target.c

target.hAdd SYNERDUINOSTM_F405 board configuration (IMU/OSD/SDIO/UART/ADC) +253/-0

Add SYNERDUINOSTM_F405 board configuration (IMU/OSD/SDIO/UART/ADC)
• Introduces SYNERDUINOSTM_F405 target identifiers and pin/bus configuration for SPI IMU variants, MAX7456 OSD, SD card (SDIO default), I2C sensor buses, UART mapping, ADC channels, PINIO outputs, and default features/scales.
src/main/target/SYNERDUINOSTM_F405/target.h

Other (2) +2 / -0

CMakeLists.txtRegister SYNERDUINOH7 STM32H743 target (HSE 25MHz) +1/-0

Register SYNERDUINOH7 STM32H743 target (HSE 25MHz)
• Adds the CMake target definition for the SYNERDUINOH7 board using the stm32h743xi family macro and a 25MHz HSE configuration, skipping releases.
src/main/target/SYNERDUINOH7/CMakeLists.txt

CMakeLists.txtRegister SYNERDUINOSTM_F405 STM32F405 target (HSE 8MHz) +1/-0

Register SYNERDUINOSTM_F405 STM32F405 target (HSE 8MHz)
• Adds the CMake target definition for the SYNERDUINOSTM_F405 board using the stm32f405xg family macro and an 8MHz HSE configuration, skipping releases.
src/main/target/SYNERDUINOSTM_F405/CMakeLists.txt

qodo-code-review · 2026-08-01T07:33:40Z

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. BMI088 not configured 🐞 Bug ≡ Correctness

Description

SYNERDUINOSTM_F405 enables USE_IMU_BMI088 but does not define the required BMI088_* SPI/I2C bus and
chip-select macros, so no BMI088 bus devices are registered and BMI088 detection/initialization will
fail. As written, the file defines BMI160_* macros instead, which are ignored by the BMI088
registration path.

Code

src/main/target/SYNERDUINOSTM_F405/target.h[R59-63]

+#define USE_IMU_BMI088
+#define IMU_BMI088_ALIGN       CW270_DEG
+#define BMI160_CS_PIN          PB12
+#define BMI160_SPI_BUS         BUS_SPI2
+

Evidence

The new target enables USE_IMU_BMI088 but never defines
BMI088_SPI_BUS/BMI088_GYRO_CS_PIN/BMI088_ACC_CS_PIN (or BMI088_I2C_BUS). The shared
registration code explicitly guards BMI088 registration on those BMI088_* macros, so no BMI088
device descriptors will exist for busDeviceInit() to discover.

src/main/target/SYNERDUINOSTM_F405/target.h[58-67]
src/main/target/common_hardware.c[68-75]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`SYNERDUINOSTM_F405/target.h` defines `USE_IMU_BMI088` but does not provide the BMI088-specific configuration macros (`BMI088_SPI_BUS` + `BMI088_GYRO_CS_PIN`/`BMI088_ACC_CS_PIN`, or `BMI088_I2C_BUS`). Because `common_hardware.c` only registers BMI088 bus devices when those BMI088_* macros exist, the firmware will have no BMI088 device descriptors and BMI088 detection will fail.

### Issue Context
This target currently sets `BMI160_CS_PIN` / `BMI160_SPI_BUS` in the BMI088 section, which doesn’t satisfy the BMI088 registration logic.

### Fix Focus Areas
- src/main/target/SYNERDUINOSTM_F405/target.h[59-67]
- src/main/target/common_hardware.c[68-75]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~SPI pin macro mismatch~~ ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

SYNERDUINOH7 enables USE_SPI_DEVICE_1 and assigns IMUs to BUS_SPI1, but defines SPI2_*_PIN
macros for PA5/PA6/PA7; these macros do not configure SPI1 and make the target configuration
misleading/fragile. SPI1 will instead use SPI1_* macros (or their defaults), so future non-default
pin changes here won’t take effect.

Code

src/main/target/SYNERDUINOH7/target.h[R100-110]

+#define USE_SPI
+#define USE_SPI_DEVICE_1
+#define SPI2_SCK_PIN            PA5 // PB13 
+#define SPI2_MISO_PIN           PA6 // PB14
+#define SPI2_MOSI_PIN           PA7 // PB15
+
+#define USE_IMU_MPU6000
+
+#define IMU_MPU6000_ALIGN       CW90_DEG
+#define MPU6000_SPI_BUS         BUS_SPI1 // BUS_SPI2
+#define MPU6000_CS_PIN          PA4 // PB12

Evidence

The target assigns IMUs to BUS_SPI1 while only defining SPI2_*_PIN macros. The SPI driver’s
hardware map for USE_SPI_DEVICE_1 uses SPI1_SCK_PIN/SPI1_MISO_PIN/SPI1_MOSI_PIN (with
defaults if not defined), so the target’s SPI2_* pin macros do not configure the active SPI bus.

src/main/target/SYNERDUINOH7/target.h[99-110]
src/main/drivers/bus_spi.c[31-36]
src/main/drivers/bus_spi.c[83-91]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`SYNERDUINOH7/target.h` selects SPI1 (`USE_SPI_DEVICE_1`, `BUS_SPI1`) but defines `SPI2_SCK_PIN`/`SPI2_MISO_PIN`/`SPI2_MOSI_PIN`. The SPI driver maps SPI1 using the `SPI1_*` macros, so these `SPI2_*` definitions are ignored for the active bus and can confuse future maintenance.

### Issue Context
Currently the defined values happen to match SPI1 defaults on many boards (PA5/PA6/PA7), but the naming mismatch means any future non-default wiring/pin changes will silently not apply.

### Fix Focus Areas
- src/main/target/SYNERDUINOH7/target.h[99-116]
- src/main/drivers/bus_spi.c[31-36]
- src/main/drivers/bus_spi.c[83-91]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Duplicate feature defines 🐞 Bug ⚙ Maintainability

Description

SYNERDUINOSTM_F405/target.h defines USE_DSHOT, USE_ESC_SENSOR, and
USE_SERIAL_4WAY_BLHELI_INTERFACE twice, which is redundant and can produce macro redefinition
warnings and maintenance confusion. The duplicates don’t add behavior (the macros are identical) but
should be collapsed into a single block.

Code

src/main/target/SYNERDUINOSTM_F405/target.h[R239-253]

+#define USE_DSHOT
+#define USE_ESC_SENSOR
+#define USE_SERIAL_4WAY_BLHELI_INTERFACE
+
+#define TARGET_IO_PORTA         0xffff
+#define TARGET_IO_PORTB         0xffff
+#define TARGET_IO_PORTC         0xffff
+#define TARGET_IO_PORTD         (BIT(2))
+
+#define MAX_PWM_OUTPUT_PORTS    10
+
+#define USE_SERIAL_4WAY_BLHELI_INTERFACE
+#define USE_DSHOT
+#define USE_DSHOT_DMAR
+#define USE_ESC_SENSOR

Evidence
The header contains two separate #define blocks for the same features (first at 239–242, then
again at 250–253).
src/main/target/SYNERDUINOSTM_F405/target.h[239-253]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
At the end of `SYNERDUINOSTM_F405/target.h`, several feature macros are defined twice (`USE_DSHOT`, `USE_ESC_SENSOR`, `USE_SERIAL_4WAY_BLHELI_INTERFACE`). This duplication is unnecessary and makes future changes error-prone.

### Issue Context
The second block also introduces `USE_DSHOT_DMAR`; keep that functionality but avoid repeating the earlier defines.

### Fix Focus Areas
- src/main/target/SYNERDUINOSTM_F405/target.h[239-253]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

qodo-code-review · 2026-08-01T07:33:42Z

+#define USE_DSHOT
+#define USE_ESC_SENSOR
+#define USE_SERIAL_4WAY_BLHELI_INTERFACE
+
+#define TARGET_IO_PORTA         0xffff
+#define TARGET_IO_PORTB         0xffff
+#define TARGET_IO_PORTC         0xffff
+#define TARGET_IO_PORTD         (BIT(2))
+
+#define MAX_PWM_OUTPUT_PORTS    10
+
+#define USE_SERIAL_4WAY_BLHELI_INTERFACE
+#define USE_DSHOT
+#define USE_DSHOT_DMAR
+#define USE_ESC_SENSOR


3. Duplicate feature defines 🐞 Bug ⚙ Maintainability

SYNERDUINOSTM_F405/target.h defines USE_DSHOT, USE_ESC_SENSOR, and USE_SERIAL_4WAY_BLHELI_INTERFACE twice, which is redundant and can produce macro redefinition warnings and maintenance confusion. The duplicates don’t add behavior (the macros are identical) but should be collapsed into a single block.

Agent Prompt

### Issue description At the end of `SYNERDUINOSTM_F405/target.h`, several feature macros are defined twice (`USE_DSHOT`, `USE_ESC_SENSOR`, `USE_SERIAL_4WAY_BLHELI_INTERFACE`). This duplication is unnecessary and makes future changes error-prone. ### Issue Context The second block also introduces `USE_DSHOT_DMAR`; keep that functionality but avoid repeating the earlier defines. ### Fix Focus Areas - src/main/target/SYNERDUINOSTM_F405/target.h[239-253]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

sensei-hacker · 2026-08-02T19:14:09Z

I suspect the difference between 9.0.1 and 9.1 is #11603 by @daijoubu
I'll defer further comment to him since he presumably understands that work better than I do.

github-actions · 2026-08-02T19:30:55Z

Test firmware build ready — commit 61fef50

Download firmware for PR #11756

243 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

daijoubu · 2026-08-02T20:27:03Z

Please correct the PLL1 and PLL2 configuration.

system_stm32h7xx.c:259): pll1Config->m = HSE_VALUE / 1000000 / 2; only works if HSE is a multiple of 2 MHz. With an HSE of 25 MHz, the existing code will incorrectly configure the PLL1 clocks. VCI will be 2.083 MHz instead of 2MHz, VCO will be 1000 MHz instead of 960 MHz and Sysclk will be 500 MHz instead of 480 MHz.
Leaving the VCI a little fast should be fine if you change the n value to get a VCO of 800 MHz. The rest of the clocks in this tree would be fine.

PLL2 had an assert added at system_stm32h7xx.c:500-514, when I fixed the silent bug with the Kakute H7 running at 16 MHz. I knew the code I added only worked for 8 MHz and 16 MHz.

At both locations the easiest will be to add this structure:
#if HSE_VALUE == 25000000
// 25 MHz-specific PLL M/N/R/Q
#else
// Existing code for 8 and 16 MHz HSE
#endif

Add files via upload

eb52a5e

qodo-code-review Bot reviewed Aug 1, 2026

View reviewed changes

synersignart changed the base branch from master to maintenance-10.x August 1, 2026 07:53

synersignart added 5 commits August 2, 2026 21:56

Add files via upload

9b30db2

Add files via upload

4c0e420

Add files via upload

09b904b

Add files via upload

5941cb0

Add files via upload

61fef50

sensei-hacker added the New target This PR adds a new target label Aug 2, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

request 2 Target for Synerduino boards - #11756

request 2 Target for Synerduino boards#11756
synersignart wants to merge 6 commits into
iNavFlight:maintenance-10.xfrom
synersignart:master

synersignart commented Aug 1, 2026

Uh oh!

github-actions Bot commented Aug 1, 2026

Uh oh!

qodo-code-review Bot commented Aug 1, 2026

Uh oh!

qodo-code-review Bot commented Aug 1, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

qodo-code-review Bot Aug 1, 2026

Uh oh!

sensei-hacker commented Aug 2, 2026

Uh oh!

github-actions Bot commented Aug 2, 2026

Uh oh!

daijoubu commented Aug 2, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

synersignart commented Aug 1, 2026

Uh oh!

github-actions Bot commented Aug 1, 2026

Branch Targeting Suggestion

Uh oh!

qodo-code-review Bot commented Aug 1, 2026

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Aug 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

qodo-code-review Bot Aug 1, 2026

Choose a reason for hiding this comment

Uh oh!

sensei-hacker commented Aug 2, 2026

Uh oh!

github-actions Bot commented Aug 2, 2026

Uh oh!

daijoubu commented Aug 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

qodo-code-review Bot commented Aug 1, 2026 •

edited

Loading

daijoubu commented Aug 2, 2026 •

edited

Loading