Add HSE define to BETAFPVG473_V2

[ot0tot]

Edit to add: Tested and confirmed working on this FC.

Summary by CodeRabbit

• Chores
  • Updated system clock frequency configuration to optimize hardware performance and stability.

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

[coderabbitai]

Walkthrough

Adds a preprocessor macro defining the system HSE (external oscillator) frequency to 8 MHz in the BETAFPVG473_V2 board configuration header. This is a configuration constant definition with no functional logic changes.

Changes

Cohort / File(s)	Summary
Board configuration update configs/BETAFPVG473_V2/config.h	Added SYSTEM_HSE_MHZ macro definition set to 8, specifying the external clock frequency for this board target

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• Add BETAFPVG473_V3 #928: Adds the same SYSTEM_HSE_MHZ macro to BETAFPVG473_V3 (sibling board variant)
• Add HGLRCF435_AIO board #884: Adds identical SYSTEM_HSE_MHZ 8 macro to HGLRCF435_AIO board config
• Add HSE to JHEG474 #847: Adds the same SYSTEM_HSE_MHZ 8 macro to a different target-specific config header

Suggested labels

Bugfix

Suggested reviewers

• haslinghuis
• sugaarK
• nerdCopter

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	No pull request description was provided; the mandatory template sections (hardware compliance, checklist, etc.) are entirely missing.	Add a comprehensive pull request description following the template, including hardware compliance information and completion of the mandatory checklist items.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding an HSE (High-Speed External clock) define to a specific 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 cbfc3be and a74e6d9.

📒 Files selected for processing (1)

• configs/BETAFPVG473_V2/config.h

🧰 Additional context used

🧠 Learnings (1)

📓 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, the manufacturer must be registered in the Manufacturers.md file. Always verify that the MANUFACTURER_ID in config.h has a corresponding entry in Manufacturers.md.

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: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: 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: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: 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: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-27T17:15:05.111Z
Learning: For Betaflight board configuration reviews, when analyzing TIMER_PIN_MAPPING definitions in config.h files, perform a comprehensive verification by: (1) Clone or access the betaflight/betaflight repository and look up each pin's timer definitions from the appropriate timer_stm32*.c file (e.g., timer_stm32h7xx.c for STM32H743, timer_stm32f4xx.c for STM32F405, etc.). (2) For each TIMER_PIN_MAP entry, verify that the timer occurrence index specified actually exists in the timer definition file for that pin. Non-existent occurrences will cause build or runtime errors. (3) Check if any timer occurrence being used is a complementary channel (ending in "N" like TIM1_CH2N, TIM8_CH3N). Complementary channels are not suitable for motor/servo control and must not be actively selected. (4) Verify that each timer channel uses a unique DMA index on MCUs with DMAMUX (like STM32H7). For MCUs without DMAMUX (like STM32F4/F7), verify non-conflicting DMA stream requests according to the appropriate DMA r...

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

🔇 Additional comments (1)

configs/BETAFPVG473_V2/config.h (1)

93-93: Approve — SYSTEM_HSE_MHZ define is correct and necessary for this board.

The 8 MHz external oscillator frequency is confirmed as standard for STM32G473 MCUs, and the manufacturer (BETAFPV Hobby) is properly registered. The BOARD_NAME also correctly matches the directory name. This define addition is essential for proper clock tree configuration.

---

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

[ot0tot]

@coderabbitai Please review all targets using F4 or G4 MCUs and identify any that are missing a system_hse_mhz define.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find all F4 and G4 MCU targets and check for SYSTEM_HSE_MHZ define

echo "=== Scanning all F4 and G4 MCU targets ==="
echo ""

# Find all config.h files in configs directory
for config_file in configs/*/config.h; do
    if [ -f "$config_file" ]; then
        # Extract target name from path
        target_name=$(echo "$config_file" | sed 's|configs/\(.*\)/config.h|\1|')
        
        # Check if it's an F4 or G4 MCU
        mcu_type=$(grep -E "^\s*#define\s+TARGET_MCU\s+" "$config_file" | awk '{print $3}')
        
        if [[ "$mcu_type" =~ STM32F4 ]] || [[ "$mcu_type" =~ STM32G4 ]]; then
            # Check if SYSTEM_HSE_MHZ is defined (case insensitive)
            has_hse=$(grep -i "^\s*#define\s\+SYSTEM_HSE_MHZ\s\+" "$config_file")
            
            if [ -z "$has_hse" ]; then
                echo "❌ MISSING: $target_name (MCU: $mcu_type)"
            else
                hse_value=$(echo "$has_hse" | awk '{print $3}')
                echo "✓ HAS: $target_name (MCU: $mcu_type, HSE: ${hse_value}MHz)"
            fi
        fi
    fi
done

echo ""
echo "=== Summary ==="
echo "Targets with F4/G4 MCUs missing SYSTEM_HSE_MHZ:"
for config_file in configs/*/config.h; do
    if [ -f "$config_file" ]; then
        target_name=$(echo "$config_file" | sed 's|configs/\(.*\)/config.h|\1|')
        mcu_type=$(grep -E "^\s*#define\s+TARGET_MCU\s+" "$config_file" | awk '{print $3}')
        
        if [[ "$mcu_type" =~ STM32F4 ]] || [[ "$mcu_type" =~ STM32G4 ]]; then
            has_hse=$(grep -i "^\s*#define\s\+SYSTEM_HSE_MHZ\s\+" "$config_file")
            
            if [ -z "$has_hse" ]; then
                echo "  - $target_name ($mcu_type)"
            fi
        fi
    fi
done

Length of output: 108

---

🏁 Script executed:

#!/bin/bash
# Let's see what MCU types are actually defined and check the pattern

echo "=== Checking all TARGET_MCU definitions ==="
echo ""

# Check all config.h files for TARGET_MCU
for config_file in configs/*/config.h; do
    if [ -f "$config_file" ]; then
        target_name=$(echo "$config_file" | sed 's|configs/\(.*\)/config.h|\1|')
        mcu_line=$(grep "define.*TARGET_MCU" "$config_file")
        if [ -n "$mcu_line" ]; then
            echo "$target_name: $mcu_line"
        fi
    fi
done | head -20

echo ""
echo "=== Checking BETAFPVG473_V2 specifically ==="
cat configs/BETAFPVG473_V2/config.h

echo ""
echo "=== Count of MCU types ==="
for config_file in configs/*/config.h; do
    if [ -f "$config_file" ]; then
        grep "define.*TARGET_MCU" "$config_file" | awk '{print $3}'
    fi
done | sort | uniq -c | sort -rn

Length of output: 4138

---

🏁 Script executed:

#!/bin/bash
# Find all F4 and G4 MCU targets and check for SYSTEM_HSE_MHZ define (corrected)

echo "=== Scanning F4 and G4 MCU targets for SYSTEM_HSE_MHZ ==="
echo ""

missing_targets=()
has_hse_targets=()

# Find all config.h files in configs directory
for config_file in configs/*/config.h; do
    if [ -f "$config_file" ]; then
        # Extract target name from path
        target_name=$(echo "$config_file" | sed 's|configs/\(.*\)/config.h|\1|')
        
        # Check if it's an F4 or G4 MCU (using FC_TARGET_MCU)
        mcu_type=$(grep "define.*FC_TARGET_MCU" "$config_file" | awk '{print $3}')
        
        if [[ "$mcu_type" =~ STM32F4 ]] || [[ "$mcu_type" =~ STM32G4 ]]; then
            # Check if SYSTEM_HSE_MHZ is defined
            has_hse=$(grep "^\s*#define\s\+SYSTEM_HSE_MHZ\s\+" "$config_file")
            
            if [ -z "$has_hse" ]; then
                echo "❌ MISSING: $target_name (MCU: $mcu_type)"
                missing_targets+=("$target_name ($mcu_type)")
            else
                hse_value=$(echo "$has_hse" | awk '{print $3}')
                has_hse_targets+=("$target_name ($mcu_type, HSE: ${hse_value}MHz)")
            fi
        fi
    fi
done

echo ""
echo "=== SUMMARY ==="
echo ""
echo "F4/G4 targets WITH SYSTEM_HSE_MHZ: ${#has_hse_targets[@]}"
echo "F4/G4 targets MISSING SYSTEM_HSE_MHZ: ${#missing_targets[@]}"
echo ""

if [ ${#missing_targets[@]} -gt 0 ]; then
    echo "Targets missing SYSTEM_HSE_MHZ define:"
    printf '%s\n' "${missing_targets[@]}"
fi

echo ""
echo "=== Sample of targets WITH HSE defined ==="
printf '%s\n' "${has_hse_targets[@]}" | head -10

Length of output: 3826

---

@ot0tot: I've completed a comprehensive scan of all F4 and G4 MCU targets in the repository. Here are the findings:

Summary

Total F4/G4 targets: 270

• ✅ With SYSTEM_HSE_MHZ defined: 221 targets
• ❌ Missing SYSTEM_HSE_MHZ: 49 targets

Targets Missing SYSTEM_HSE_MHZ

STM32G47X (G4) - 9 targets missing:

1. AIRBOTG4AIO
2. GEPRC_TAKER_G473AIO
3. KAKUTEG4AIO
4. LUXHDAIO-G4
5. LUXMICROAIO
6. MAMBAG4
7. NUCLEOG474
8. SUB250_REDFOX_G473AIO
9. TAKERG4AIO

STM32F405 (F4) - 28 targets missing:

ACCIF405, AIKONF4V2, ALIENFLIGHTF4, CADDXF4, CADDX_PROTOS_F4, CYCLONEF405_PRO, DAKEFPVF405, DREAMFLYF405, EAGLEF405, FF_RACEPIT, FF_RACEPIT_MINI, FLAOF405X8, FLYCOLORF4, HAKRCF405V2, HGLRCF405V2, MAMBAF405US, MAMBAF405US_I2C, MAMBAF405_2022A, MAMBAF405_2022B, NEUTRONRCF407, OMNIBUSF4NANOV7, RUSRACE_F4, SKYSTARSF405AIO, STELLARF4, STELLARF4V2, TCMM405V3, VGOODRCF405_DJI

STM32F411 (F4) - 11 targets missing:

ATOMRCF411, FLYWOOF411_5IN1_AIO, FOSSF4ELRS, GEELANGF411, GEPRCF411SX1280, HAKRCF411D, JHEF411HD, MAMBAF411, NEUTRONRCF411AIO, NEUTRONRCF411SX1280, TCMMF411, VGOODRCF411_DJI

STM32F446 (F4) - 1 target missing:

NUCLEOF446

Note

This PR correctly adds the SYSTEM_HSE_MHZ define to BETAFPVG473_V2. Would you like me to help track these other 48 missing targets by creating an issue for follow-up?

---

🧠 Learnings used

Learnt from: osirisinferi
Repo: betaflight/config PR: 0
File: :0-0
Timestamp: 2025-12-27T17:15:05.111Z
Learning: For Betaflight board configuration reviews, when analyzing TIMER_PIN_MAPPING definitions in config.h files, perform a comprehensive verification by: (1) Clone or access the betaflight/betaflight repository and look up each pin's timer definitions from the appropriate timer_stm32*.c file (e.g., timer_stm32h7xx.c for STM32H743, timer_stm32f4xx.c for STM32F405, etc.). (2) For each TIMER_PIN_MAP entry, verify that the timer occurrence index specified actually exists in the timer definition file for that pin. Non-existent occurrences will cause build or runtime errors. (3) Check if any timer occurrence being used is a complementary channel (ending in "N" like TIM1_CH2N, TIM8_CH3N). Complementary channels are not suitable for motor/servo control and must not be actively selected. (4) Verify that each timer channel uses a unique DMA index on MCUs with DMAMUX (like STM32H7). For MCUs without DMAMUX (like STM32F4/F7), verify non-conflicting DMA stream requests according to the appropriate DMA request mapping for that platform. Use sequential indices (0,1,2,3,4,5,6,7...) with -1 reserved only for pins that don't require DMA. (5) Verify that LED_STRIP_PIN has a valid DMA index (not -1) on platforms with DMAMUX, because WS2812/addressable LEDs require DMA for timing-critical operations. (6) Check that all defined CLKIN pins (like GYRO_1_CLKIN_PIN, GYRO_2_CLKIN_PIN) are included in the TIMER_PIN_MAPPING with appropriate timer occurrence and DMA -1. This systematic verification must be performed for all new or modified TIMER_PIN_MAPPING definitions before approval.

---

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: 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, the manufacturer must be registered in the Manufacturers.md file. Always verify that the MANUFACTURER_ID in config.h has a corresponding entry in Manufacturers.md.

---

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: 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: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: 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, 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.