FLYWOOF722PROV2: target for the Flywoo GOKU F722 Pro V2

[MrScothh]

The F722 Pro V2 runs today on FLYWOOF722PRO, whose pins all match it, but that target cannot see what the V2 adds over the V1: Betaflight's FLYWOOF722PROV2 config lists an LSM6DSK320X as the alternative to the ICM-42688-P, a footprint for a second IMU on the same SPI bus, and the DPS310 as its only barometer driver.

What changes

FLYWOOF722PROV2 as a variant in the FLYWOOF722PRO folder, the V1 target unchanged:

• Its own target name, which the board reports over MSP, so the Configurator offers the right firmware.
• IMU on CS PA4: ICM-42688-P (ICM42605 driver) or LSM6DSK320X (LSM6DXX driver), both CW270 as in Betaflight's config. The V1's MPU6000 and BMI270 options are left out.
• Second IMU on CS PB2, same SPI1, same two chips and alignment, with USE_DUAL_GYRO: gyro_to_use = 1 selects it, and gyro_secondary_enabled logs it.
• Barometer: only the DPS310 driver, as in Betaflight's config. Flywoo lists the V2 with a DPS310 or an SPL06: both answer the same chip ID, and the DPS310 driver reads either, as Betaflight's does (on a Mamba F722 2022B, whose baro Diatone lists as SPL06, INAV's DPS310 driver reads 17.0 °C, against 44.0 °C through the SPL06 driver). Building only that driver also keeps baro_hardware = AUTO from taking the chip, at 0x76, for an SPL06, which happens on targets that build both drivers: the SPL06 driver reads this board's baro about 26 °C too warm.
• The Puya PY25Q128HA flash, the V2's alternative to the W25Q128FV, needs nothing: its JEDEC id 0x852018 is already in the M25P16 driver's table.

Moving a V2 from FLYWOOF722PRO

A V2 that runs FLYWOOF722PRO today needs its settings reset when it moves to this target: flash with full chip erase, or run defaults after flashing. USE_DUAL_GYRO adds gyro_to_use to the gyro settings, so a record saved by FLYWOOF722PRO loads shifted. On the test board, flashed with the settings kept, it showed GYRO and ACC unavailable, gyro_to_use = 60 and SETTINGFAIL until defaults. The layout differs between the two targets, not between versions, so there is no PG version to bump.

Tested

• Built on maintenance-10.x with warnings as errors, as CI does: FLYWOOF722PROV2 uses 479,947 B of flash (97.6 %), 92,752 B of RAM and 11,424 B of ITCM. FLYWOOF722PRO builds to the same sizes as before the change (482,455 B flash, 92,800 B RAM, 11,600 B ITCM): its code is untouched, only wrapped in #ifdef.
• On a V2 with an ICM-42688-P, a DPS310 and a W25Q128, no second IMU fitted:
  • version reports FLYWOOF722PROV2. status: GYRO and ACC ICM42605, BARO DPS310 with baro_hardware = AUTO, 16 MB flash, OSD MAX7456, GPS on UART5, 50 I2C errors at boot as on the V1 target.
  • Axes: with the board turned by hand, the gravity the gyro integrates agrees with the accelerometer to 8.5° (median) with CW270, and to 64° with the signs flipped. The same board on FLYWOOF722PRO gives 8.0°.
  • gyro_secondary_enabled = ON with no second IMU: boots, status unchanged. gyro_to_use = 1: the gyro shows as unavailable and everything else keeps working; back to 0, it is normal again.
  • Blackbox: 48 s logged to the flash, downloaded over MSP and decoded.

Not tested, no hardware: the LSM6DSK320X variant, a populated second IMU and the Puya flash. With the LSM6DSK320X the gyro runs at 8 kHz, as on DAKEFPVF722, and its CW270 alignment is the one Betaflight uses for both chips. The data-ready pins, PC3 for the first IMU and PC4 for the second as in Betaflight's config, are left out: they belong with my open data-ready PRs. #12065 and #12067 merge cleanly with this one but give PC3 to FLYWOOF722PRO only, and #12066 conflicts with it in target.c and target.h; whichever lands second, this PR or those, adds the V2's pins. If you have a V2 with the LSM6DSK320X or a second IMU, status and the Sensors tab after flashing would tell.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add Flywoo GOKU F722 Pro V2 firmware target

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add a distinct V2 firmware target and board identity while preserving V1 behavior.
• Support either V2 IMU in both SPI1 slots, with optional secondary gyro selection.
• Restrict V2 barometer detection to DPS310; reset saved settings when migrating from the V1 target.

Diagram

graph TD
  C["CMake targets"] --> H["Shared target files"] --> V["V2 configuration"] --> D["IMU descriptors"] --> S["SPI1 IMUs"]
  H --> O["V1 configuration"]
  V --> B["DPS310 driver"]

Loading

High-Level Assessment

Sharing the target files with conditional V2 sensor definitions fits boards whose other pins match. Duplicating the target directory would invite drift, while extending V1 through runtime detection would not provide a distinct board identity or isolate V2's barometer support.

Files changed (3) +30 / -1

Enhancement (1) +7 / -0

target.cRegister V2 IMU options on both SPI slots +7/-0

Register V2 IMU options on both SPI slots

• Registers ICM42605 and LSM6DXX descriptors for each V2 IMU chip-select pin, with distinct sensor tags. Keeps the existing V1 registrations in the other compile-time branch.

src/main/target/FLYWOOF722PRO/target.c

Other (2) +23 / -1

CMakeLists.txtRegister the V2 firmware build +1/-0

Register the V2 firmware build

• Adds FLYWOOF722PROV2 as a separate STM32F722 target alongside the existing build.

src/main/target/FLYWOOF722PRO/CMakeLists.txt

target.hDefine V2 identity and sensor capabilities +22/-1

Define V2 identity and sensor capabilities

• Gives V2 its own USB product string, enables dual-gyro support, and defines the SPI1 pins and CW270 alignment for its IMU options. Builds only the DPS310 barometer driver for V2 while retaining V1's existing IMU and barometer options.

src/main/target/FLYWOOF722PRO/target.h

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Upgrades without erasing lose the gyro 🐞 Bug ≡ Correctness

Description

USE_DUAL_GYRO inserts gyro_to_use into the middle of the persisted gyro settings structure, but
the gyro settings record keeps the same version. When V2 firmware loads settings saved by
FLYWOOF722PRO, it interprets an old filter-setting byte as the gyro selection and shifts later
settings, so it can select a nonexistent sensor until the settings are reset.

Code

src/main/target/FLYWOOF722PRO/target.h[42]

+#define USE_DUAL_GYRO

Evidence

The new macro activates a field inserted before existing settings. The loader copies saved bytes
whenever the record version matches, and gyro initialization uses the resulting field directly as
the sensor tag.

src/main/target/FLYWOOF722PRO/target.h[40-42]
src/main/sensors/gyro.h[78-88]
src/main/sensors/gyro.c[123-129]
src/main/config/parameter_group.c[86-94]
src/main/config/config_eeprom.c[223-237]
src/main/sensors/gyro.c[350-358]

Agent prompt

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

## Issue description
V2 firmware accepts V1 gyro settings despite inserting a field into their serialized layout. Flashing without erasing can select a nonexistent gyro.

## Fix Focus Areas
- src/main/target/FLYWOOF722PRO/target.h[40-42]
- src/main/sensors/gyro.c[123-129]

## Recommended Fix
Give the V2 gyro settings record a distinct version so the existing loader resets that record instead of copying incompatible bytes, or explicitly migrate the V1 layout. Preserve the existing version for the V1 target.

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

---

Context sources

Review mode: Auto: ⚖️ Balanced: Hardware target and sensor configuration changes carry meaningful runtime risk.

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[github-actions]

Test firmware build ready — commit c9b15a0

Download firmware for PR #12112

2 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.

[github-actions]

RAM / Flash usage vs. base commit e87050f — commit c9b15a0

Using the nearest available size baseline — the PR's exact base commit has no stored baseline yet.

None of the representative targets (MATEKF405, MATEKF722, MATEKF765, MATEKH743) were built by this PR — no size comparison to show.

See RAM/flash optimization guide for techniques to reduce usage.