RADIOLINKF722 add W25Q128FV FLASH

[radiolinkW]

Pull-Request requirements

Mandatory Review for All New Flight Controllers

• All new flight controllers must undergo the Betaflight review process, regardless of whether they use an existing target.
• Manufacturers may reuse the same target for multiple designs, but each new hardware release must be reviewed before approval.

Hardware Compliance Requirements

• All hardware must adhere to the Manufacturer Design Guidelines.
• Poor hardware designs will not be accepted, as outlined in the Requirements for the Submission of New and Updated Targets.
• Adhere to the [Config Target Guidance] https://betaflight.com/docs/development/manufacturer/config-target-guidance
• To avoid costly issues and delays, we strongly encourage consulting with Betaflight developers early in your design process and providing schematics for review before producing hardware.

These measures help maintain high standards and ensure compatibility within the Betaflight ecosystem.

If you have any questions or need guidance, feel free to reach out to the Betaflight development team.

Housekeeping

• Pull-Request only from a custom branch, not master.
• Replace this text with details of your own.

Checklist (✓/✕, or y/n)

• passed Betaflight team's schematics review
• passed hardware samples testing
• follows guidelines
• follows connector standards
• flight tested
• comments/issues resolved

Summary by CodeRabbit

• New Features
  • Enabled support for W25Q128FV flash memory devices, expanding hardware compatibility options.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added a preprocessor macro definition to enable W25Q128FV flash device support in the RADIOLINKF722 board configuration. This is a single-line configuration flag with no functional or control-flow modifications.

Changes

Cohort / File(s)	Summary
RADIOLINKF722 Configuration configs/RADIOLINKF722/config.h	Added #define USE_FLASH_W25Q128FV macro to enable W25Q128FV flash device support for this board.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• Add SIMPLIFLYH7 #927: Adds the same W25Q128FV flash support macro to a different board's configuration file.

Suggested reviewers

• haslinghuis
• blckmn
• nerdCopter

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description reproduces the mandatory template without replacing placeholder text with actual submission details as explicitly required by the template ('Replace this text with details of your own').	Replace the template boilerplate with specific details about this W25Q128FV flash addition, and mark the relevant checklist items to indicate completion status of the review requirements.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'RADIOLINKF722 add W25Q128FV FLASH' clearly and specifically describes the main change: adding W25Q128FV flash support to the RADIOLINKF722 flight controller configuration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2cc4bcc and 89fd670.

📒 Files selected for processing (1)

• configs/RADIOLINKF722/config.h

🧰 Additional context used

🧠 Learnings (8)

📓 Common learnings

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:09:11.644Z
Learning: For Betaflight board configuration reviews, maintainer information must be included in target submissions according to the Requirements for Submission of New and Updated Targets.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:09:11.644Z
Learning: For Betaflight board configuration reviews, schematics are mandatory for all new target submissions. Submissions without schematics for review should be rejected according to the Config Target Guidance.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:09:11.644Z
Learning: For Betaflight board configuration reviews, F411 MCU, SPI-based RX, and BMI270 gyro are deprecated platforms as of September 16, 2024. New target submissions using these should be flagged.

Learnt from: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T21:03:53.169Z
Learning: For Betaflight board configuration reviews, schematics are mandatory for the overall review process according to the Config Target Guidance, but they do NOT need to be provided publicly in the GitHub PR itself. Schematics review is conducted through a separate/private channel. Do not flag "missing schematics in PR" as a blocking issue.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:09:11.644Z
Learning: For Betaflight board configuration reviews, STM32 F4 and F7 based designs with more than 4 motor outputs are not accepted for new submissions after December 3, 2024. This is an official timeline restriction from the Config Target Guidance.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:09:11.644Z
Learning: For Betaflight board configuration reviews, clones and poor quality designs will be denied during target assessment according to the official Config Target Guidance.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:17:04.545Z
Learning: For Betaflight board configuration reviews, documentation requirements include: published schematics/KiCad files, SWD programming pads or header following the SWD pin mapping specification, connector pinouts, and clear board revision notes so Betaflight Configurator can link board documentation according to the Manufacturer Design Guidelines.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:09:11.644Z
Learning: For Betaflight board configuration reviews, commercial target submissions require payment of a target fee. This should be verified as part of the submission requirements.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:17:04.545Z
Learning: For Betaflight board configuration reviews, hardware design must follow the Manufacturer Design Guidelines: proper power regulation with good ground/power planes and decoupling, redundant solder pads or castellations for durability, oversized mounting holes for M3 stack robustness, clear silkscreen pin labels and revision marking, and high-speed signals routed away from noisy power traces.

Learnt from: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T21:01:01.473Z
Learning: For Betaflight board configuration reviews, when blocking issues are identified after an initial approval, immediately dismiss/withdraw the approval by using `gh pr review <PR_NUMBER> --repo betaflight/config --request-changes --body "<reason>"` to change the review state to CHANGES_REQUESTED. This actively manages approval status to ensure it accurately reflects the current mergability state of the PR.

Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.

Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Learnt from: haslinghuis
Repo: betaflight/config PR: 792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition.

Learnt from: haslinghuis
Repo: betaflight/config PR: 792
File: configs/BEEROTORF4/config.h:30-30
Timestamp: 2025-05-28T15:42:05.402Z
Learning: The DEFAULT_GYRO_ENABLED macro with both gyros enabled (GYRO_MASK(0) | GYRO_MASK(1)) should only be added to board configurations that have DEFAULT_GYRO_TO_USE set to GYRO_CONFIG_USE_GYRO_BOTH. Boards without this setting should only get the GYRO_COUNT definition to specify the number of available gyros.

Learnt from: blckmn
Repo: betaflight/config PR: 851
File: configs/HELLBENDER_0001/config.h:45-46
Timestamp: 2025-08-10T14:08:56.662Z
Learning: In Betaflight, USE_LED_STRIP is a cloud build option that enables/disables the LED strip feature at build time. Individual target config files (configs/*/config.h) only need to define LED_STRIP_PIN as a default pin assignment - they should not define USE_LED_STRIP themselves. The feature enablement is handled externally through the cloud build system, not through preprocessor directives in the config files.

Learnt from: haslinghuis
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-07-03T15:17:30.040Z
Learning: In Betaflight configurations, when a target name suggests dual IMUs (like JHEF7DUAL) but specific hardware variants only have one gyro available, the preferred solution is to use DEFAULT_GYRO_TO_USE macro to specify which gyro to use by default rather than pruning gyro defines or creating redundant configurations. This approach maintains compatibility when the same target is used by multiple hardware variants from the same manufacturer.

📚 Learning: 2025-06-23T18:43:31.746Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:29-37
Timestamp: 2025-06-23T18:43:31.746Z
Learning: In Betaflight configuration files, feature enablement macros like USE_MAG are build options that can be controlled at compile time, while hardware instance definitions like MAG_I2C_INSTANCE are predefined in board configurations to assist with hardware mapping when those features are enabled at build time.

Applied to files:

• configs/RADIOLINKF722/config.h

📚 Learning: 2025-08-10T14:08:56.662Z

Learnt from: blckmn
Repo: betaflight/config PR: 851
File: configs/HELLBENDER_0001/config.h:45-46
Timestamp: 2025-08-10T14:08:56.662Z
Learning: In Betaflight, USE_LED_STRIP is a cloud build option that enables/disables the LED strip feature at build time. Individual target config files (configs/*/config.h) only need to define LED_STRIP_PIN as a default pin assignment - they should not define USE_LED_STRIP themselves. The feature enablement is handled externally through the cloud build system, not through preprocessor directives in the config files.

Applied to files:

• configs/RADIOLINKF722/config.h

📚 Learning: 2025-07-25T20:06:07.492Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T20:06:07.492Z
Learning: BMP280 and DPS310 barometer drivers in Betaflight do not require USE_I2C to be explicitly defined in board configurations. Many existing boards successfully use USE_BARO_BMP280 and USE_BARO_DPS310 without defining USE_I2C, indicating that the I2C dependency is handled automatically by the build system or these sensors support alternative communication methods.

Applied to files:

• configs/RADIOLINKF722/config.h

📚 Learning: 2025-07-25T20:06:07.492Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 719
File: configs/SPEDIXG473/config.h:29-38
Timestamp: 2025-07-25T20:06:07.492Z
Learning: BMP280 and DPS310 barometer drivers in Betaflight do not require USE_I2C to be explicitly defined in board configurations. Out of 264 boards using these drivers, 259 (98%) work without USE_I2C defined, indicating that the I2C dependency is handled automatically by the build system.

Applied to files:

• configs/RADIOLINKF722/config.h

📚 Learning: 2025-06-23T18:44:59.162Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 822
File: configs/AXISFLYINGH7MINI/config.h:121-129
Timestamp: 2025-06-23T18:44:59.162Z
Learning: In Betaflight configuration files, USE_OSD_HD and USE_MAX7456 are for different OSD systems: USE_MAX7456 enables the MAX7456 analog OSD chip, while USE_OSD_HD enables HD/digital OSD via MSP. MSP_DISPLAYPORT_UART should be guarded by USE_OSD_HD, not USE_MAX7456, as they serve different OSD implementations.

Applied to files:

• configs/RADIOLINKF722/config.h

📚 Learning: 2025-08-22T17:08:23.283Z

Learnt from: haslinghuis
Repo: betaflight/config PR: 879
File: configs/AIRBOTSUPERF4V2/config.h:42-45
Timestamp: 2025-08-22T17:08:23.283Z
Learning: In Betaflight board configurations, OSD feature flags like USE_OSD_SD (analog/MAX7456) and USE_OSD_HD (digital/MSP DisplayPort) are typically defined at build time by the build system, not in the individual board config.h files. Board configs can conditionally define OSD-related settings based on these build-time flags.

Applied to files:

• configs/RADIOLINKF722/config.h

📚 Learning: 2025-12-30T20:33:02.562Z

Learnt from: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-30T20:33:02.562Z
Learning: For Betaflight board configuration reviews, PC13, PC14, and PC15 must never be used for status LED pins (LED0_PIN, LED1_PIN, LED2_PIN, etc.) because these pins are on the STM32 RTC/backup domain with severely limited current drive capability (~3mA max) and cannot directly drive LED indicators. However, LED_STRIP_PIN is permitted on these pins since it only outputs digital timing signals to addressable LED controllers and does not directly sink or source significant current.

Applied to files:

• configs/RADIOLINKF722/config.h

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Setup Build Environment

🔇 Additional comments (4)

configs/RADIOLINKF722/config.h (4)

37-39: Clarify the dual flash chip configuration.

The configuration defines both USE_FLASH_W25N01G and USE_FLASH_W25Q128FV with a single FLASH_CS_PIN (PD2) and FLASH_SPI_INSTANCE (SPI3). This is unusual - typically a board configuration specifies a single flash chip type.

Possible interpretations:

1. Hardware variants exist with different flash chips
2. Runtime detection is used to identify the installed chip
3. Configuration error

Please clarify:

• Does this board have hardware variants with different flash chips?
• Is runtime flash detection implemented in the firmware?
• Should there be separate configurations for each variant?

---

42-42: Verify beeper functionality on PC13.

PC13 is on the STM32 RTC/backup domain with limited current drive capability (~3mA max). While the retrieved learnings specifically mention that PC13/PC14/PC15 must not be used for status LEDs, beepers typically require 10-30mA to function properly.

Verify that:

• The beeper circuit includes external buffering/driving circuitry, or
• The beeper is specifically designed for low-current operation

This should be confirmed during hardware testing and schematics review.

Based on learnings about STM32 RTC domain pin limitations.

---

24-27: Ensure all submission requirements are met.

For Betaflight target submissions, please confirm:

1. Target fee: Payment has been completed for this commercial target
2. Maintainer information: Manufacturer contact details are provided (MANUFACTURER_ID is set to RALI)
3. Documentation: Published schematics/KiCad files, SWD programming access, connector pinouts, and board revision notes
4. Hardware compliance: Design follows Manufacturer Design Guidelines (proper power regulation, redundant pads, mounting holes, silkscreen labels)
5. Checklist completion: All items in the PR checklist should be marked complete before merge

The PR description shows the checklist is not yet marked complete.

Based on learnings about Betaflight submission requirements.

---

24-50: This is an update to an existing target, not a new submission—motor count and BMI270 restrictions do not apply.

RADIOLINKF722 was already added to the repository in commit 60073b7 and exists in the master branch. This PR simply adds support for an additional flash chip option (W25Q128FV). The Betaflight restrictions on STM32 F7 boards with >4 motors and BMI270 gyros apply only to new target submissions; since RADIOLINKF722 was previously approved, those constraints are not blocking factors for this update.

The flash chip addition itself appears straightforward and should be verified for correctness only.

Likely an incorrect or invalid review comment.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}