add STARTFPVG473 config floder and config.h #892
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
WalkthroughAdds a new Betaflight board configuration header for STARTFPVG473 (STM32G47X). The file defines pins, peripherals (SPI/I2C/UART), DMA options, sensor and device enables (ACC/GYRO, BMI270/ICM42688P, BARO, FLASH, MAX7456), default runtime options (DSHOT, blackbox, meters), and timer pin mappings. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10–15 minutes Possibly related PRs
Suggested reviewers
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (5)
configs/STARTFPVG473/config.h (5)
27-28: BOARD_NAME matches directory; MANUFACTURER_ID should be 4 charsGood: BOARD_NAME equals STARTFPVG473 (matches folder). Use a 4‑char MANUFACTURER_ID per common Betaflight convention to avoid tooling/UI quirks.
Apply:
-#define MANUFACTURER_ID ST +#define MANUFACTURER_ID STPV
21-21: Remove “test file” note from production configStray “it’s test file” comment looks accidental and can confuse target consumers.
-/*it's test file*/
30-41: Enable dual-IMU autodetect explicitlyYou’ve enabled both ICM42688P and BMI270. Recommend setting DEFAULT_GYRO_TO_USE to “both” for clean autodetect, per prior guidance.
#define USE_MAX7456 + +// Prefer runtime autodetect when multiple gyro drivers are enabled +#define DEFAULT_GYRO_TO_USE GYRO_CONFIG_USE_GYRO_BOTH
98-101: Finalize DSHOT defaults; drop TODOAvoid TODOs in target configs. Either define DSHOT_IDLE_VALUE explicitly or remove the line.
-//TODO #define DSHOT_IDLE_VALUE 450 +#define DSHOT_IDLE_VALUE 450Optional: If DMA mapping is valid, consider DEFAULT_DSHOT_BURST = DSHOT_DMAR_ON for reduced CPU load.
102-106: Calibrate meter defaults and beeper polarity
- DEFAULT_CURRENT_METER_SCALE=750 is a placeholder; request calibration against your shunt/OpAmp.
- BEEPER_INVERTED may need flipping depending on transistor stage.
I can compute correct scales from shunt (mΩ), sense gain, and ADC resistor ladder ratios if you share those values.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
configs/STARTFPVG473/config.h(1 hunks)
🧰 Additional context used
🧠 Learnings (12)
📓 Common learnings
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Learnt from: ot0tot
PR: betaflight/config#872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.
Learnt from: haslinghuis
PR: betaflight/config#656
File: configs/IFLIGHT_F745_AIO/config.h:31-35
Timestamp: 2025-07-28T16:44:59.686Z
Learning: In Betaflight board configurations, when a board design uses the same physical gyro socket but different sensor variants across production batches (e.g., MPU6000 in older batches, ICM42688P in newer batches), the correct approach is to enable both sensor drivers (USE_GYRO_SPI_MPU6000 and USE_GYRO_SPI_ICM42688P) in the same configuration. This allows runtime auto-detection of which sensor is actually present without requiring separate board configurations for each hardware variant.
Learnt from: haslinghuis
PR: betaflight/config#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
PR: betaflight/config#888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.
Learnt from: haslinghuis
PR: betaflight/config#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
PR: betaflight/config#870
File: configs/ZEX_ATHENA_STD_PRO/config.h:54-55
Timestamp: 2025-08-21T11:11:19.213Z
Learning: For STM32H743 in Betaflight, UART4 can use PB8 (UART4_RX) and PB9 (UART4_TX) as confirmed in the official Betaflight codebase at src/platform/STM32/serial_uart_stm32h7xx.c. This contradicts some generic STM32 documentation that might not show all supported pin configurations used by Betaflight.
Learnt from: haslinghuis
PR: betaflight/config#757
File: configs/HAKRCH743/config.h:134-134
Timestamp: 2025-08-05T16:56:44.200Z
Learning: In Betaflight board configurations, when DEFAULT_GYRO_TO_USE is set to GYRO_CONFIG_USE_GYRO_BOTH, the firmware automatically establishes GYRO_COUNT during initialization for backwards compatibility. Therefore, explicit GYRO_COUNT definitions are not needed in board config files when using DEFAULT_GYRO_TO_USE.
Learnt from: haslinghuis
PR: betaflight/config#870
File: configs/ZEX_ATHENA_STD_PRO/config.h:54-55
Timestamp: 2025-08-21T11:11:19.213Z
Learning: For STM32H743 in Betaflight, UART4 can use PB8 (UART4_RX) and PB9 (UART4_TX) with GPIO_AF8_UART4, as confirmed in the official Betaflight codebase at src/platform/STM32/serial_uart_stm32h7xx.c. This is a valid pin mapping despite what some generic STM32 documentation might suggest.
Learnt from: haslinghuis
PR: betaflight/config#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-07-14T16:16:56.822Z
Learnt from: haslinghuis
PR: betaflight/config#835
File: configs/HDZERO_HALO_MPU6000/config.h:44-56
Timestamp: 2025-07-14T16:16:56.822Z
Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-07-03T04:33:57.480Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-03T04:33:57.480Z
Learning: Always verify that the BOARD_NAME define in each config.h matches the directory name it resides in (e.g., configs/AXISFLYINGF7AIO/config.h must have #define BOARD_NAME AXISFLYINGF7AIO). This check is required for all Betaflight board configuration reviews.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-06-23T18:43:31.746Z
Learnt from: haslinghuis
PR: betaflight/config#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/STARTFPVG473/config.h
📚 Learning: 2025-08-22T17:08:23.283Z
Learnt from: haslinghuis
PR: betaflight/config#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/STARTFPVG473/config.h
📚 Learning: 2025-06-02T16:16:20.197Z
Learnt from: haslinghuis
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-06-02T16:16:20.197Z
Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
PR: betaflight/config#888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines (like ESC_SENSOR_UART, MSP_UART, GPS_UART, etc.) use valid SERIAL_PORT identifiers that match those defined in the Betaflight codebase at src/main/io/serial.h. Common valid identifiers include SERIAL_PORT_USART1, SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, etc. Invalid identifiers like SERIAL_PORT_UART3 (should be SERIAL_PORT_USART3) will cause build failures.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-08-20T02:54:58.596Z
Learnt from: ot0tot
PR: betaflight/config#872
File: configs/HGLRCH743/config.h:82-83
Timestamp: 2025-08-20T02:54:58.596Z
Learning: For Betaflight board configuration reviews, the definitive source for validating UART pin assignments is the serial_uart_{platform}.c file in the Betaflight codebase (e.g., serial_uart_stm32h7xx.c for STM32H7xx platforms), not generic MCU datasheets. These files contain the exact pin mappings that Betaflight supports for each UART peripheral.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-07-23T13:43:50.456Z
Learnt from: ot0tot
PR: betaflight/config#0
File: :0-0
Timestamp: 2025-07-23T13:43:50.456Z
Learning: For Betaflight board configuration reviews, always verify that serial port defines use valid identifiers from the serialPortIdentifier_e enum in src/main/io/serial.h. Valid identifiers include: SERIAL_PORT_USB_VCP (20), SERIAL_PORT_SOFTSERIAL1 (30), SERIAL_PORT_SOFTSERIAL2 (31), SERIAL_PORT_LPUART1 (40), SERIAL_PORT_UART0 (50, if SERIAL_UART_FIRST_INDEX == 0), SERIAL_PORT_USART1 (51 or 50), SERIAL_PORT_USART2, SERIAL_PORT_USART3, SERIAL_PORT_UART4, SERIAL_PORT_UART5, SERIAL_PORT_USART6, SERIAL_PORT_USART7, SERIAL_PORT_USART8, SERIAL_PORT_UART9, SERIAL_PORT_USART10. While some aliases exist (like SERIAL_PORT_UART3 = SERIAL_PORT_USART3), prefer using the primary identifiers as referenced in the serialPortIdentifiers array to avoid build failures.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-08-28T20:45:36.652Z
Learnt from: haslinghuis
PR: betaflight/config#888
File: configs/ZEX_ATHENA_MINI/config.h:0-0
Timestamp: 2025-08-28T20:45:36.652Z
Learning: In STM32H743 Betaflight configurations, PB0 can use multiple timer options including TIM1_CH2N, TIM3_CH3, and TIM8_CH2N as defined in timer_stm32h7xx.c. For CAMERA_CONTROL_PIN assignments, TIM3_CH3 (timer index 3) is the appropriate choice.
Applied to files:
configs/STARTFPVG473/config.h
📚 Learning: 2025-07-03T15:17:30.040Z
Learnt from: haslinghuis
PR: betaflight/config#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.
Applied to files:
configs/STARTFPVG473/config.h
🔇 Additional comments (4)
configs/STARTFPVG473/config.h (4)
85-90: DMA option indices need validation against G4 backendVerify that SPIx_TX/RX DMA option values (14/10/9/13/11/8) and ADC1_DMA_OPT=6 correspond to valid streams/requests on STM32G4 and don’t conflict with timers used by motors/LED/blackbox.
I can help cross-walk these to the dma_stm32g4xx tables once you confirm the intended timers and SPI usage.
92-94: Serial port identifiers look correct; confirm pin support in G4 backendSERIAL_PORT_USART2/USART3 are valid ids. Ensure PC10/PC11 as UART4 are actually present on STM32G47x and supported by Betaflight (pins are defined above but not assigned here).
107-110: Peripheral instance wiring looks coherentMAX7456 on SPI2 (PB12–PB15) and FLASH on SPI3 (PB3–PB5) align with the defined pins. GYRO on SPI1 with PA4 CS is standard. GYRO_1_ALIGN=CW180_DEG is fine if silkscreen arrow reflects this.
Please confirm the gyro orientation versus the board arrow.
56-57: Use PB6/PB7 for I2C1 pins
PA15 isn’t a supported SCL pin for I2C1 on STM32G4; bus 1 only maps to PB6/PB7 (community.st.com, githubhelp.com)-#define I2C1_SCL_PIN PA15 -#define I2C1_SDA_PIN PB7 +#define I2C1_SCL_PIN PB6 +#define I2C1_SDA_PIN PB7⛔ Skipped due to learnings
Learnt from: haslinghuis PR: betaflight/config#888 File: configs/ZEX_ATHENA_MINI/config.h:0-0 Timestamp: 2025-08-28T20:45:36.652Z Learning: In STM32H743 Betaflight configurations, PA15 maps to TIM2_CH1 (timer index 2) as defined in timer_stm32h7xx.c. When used for GYRO_CLKIN functionality, it's recommended to use the macro name GYRO_1_CLKIN_PIN in TIMER_PIN_MAPPING for consistency with other pin definitions.Learnt from: haslinghuis PR: betaflight/config#870 File: configs/ZEX_ATHENA_STD_PRO/config.h:54-55 Timestamp: 2025-08-21T11:11:19.213Z Learning: For STM32H743 in Betaflight, UART4 can use PB8 (UART4_RX) and PB9 (UART4_TX) as confirmed in the official Betaflight codebase at src/platform/STM32/serial_uart_stm32h7xx.c. This contradicts some generic STM32 documentation that might not show all supported pin configurations used by Betaflight.Learnt from: haslinghuis PR: betaflight/config#870 File: configs/ZEX_ATHENA_STD_PRO/config.h:54-55 Timestamp: 2025-08-21T11:11:19.213Z Learning: For STM32H743 in Betaflight, UART4 can use PB8 (UART4_RX) and PB9 (UART4_TX) with GPIO_AF8_UART4, as confirmed in the official Betaflight codebase at src/platform/STM32/serial_uart_stm32h7xx.c. This is a valid pin mapping despite what some generic STM32 documentation might suggest.Learnt from: ot0tot PR: betaflight/config#834 File: configs/RADIOLINKF405/config.h:79-88 Timestamp: 2025-07-14T15:41:14.364Z Learning: In STM32F405 configurations, PB1 typically maps to TIM3_CH4 and PC9 typically maps to TIM8_CH4. These are different timers and do not share DMA resources, so there is no conflict when both pins are used simultaneously (e.g., PB1 for LED_STRIP and PC9 for MOTOR4).Learnt from: haslinghuis PR: betaflight/config#798 File: configs/FURYF4OSD/config.h:88-88 Timestamp: 2025-05-31T17:01:39.423Z Learning: For STM32F4xx platforms, PB1 pin timer definitions are: 1 = DEF_TIM(TIM1, CH3N, PB1, 0, 0) 2 = DEF_TIM(TIM3, CH4, PB1, 0, 0) 3 = DEF_TIM(TIM8, CH3N, PB1, 0, 0) Timer instance 2 (TIM3, CH4) is the correct mapping for PB1 motor control on STM32F4xx platforms as defined in src/platform/STM32/timer_stm32f4xx.cLearnt from: haslinghuis PR: betaflight/config#888 File: configs/ZEX_ATHENA_MINI/config.h:0-0 Timestamp: 2025-08-28T20:45:36.652Z Learning: In STM32H743 Betaflight configurations, PB0 can use multiple timer options including TIM1_CH2N, TIM3_CH3, and TIM8_CH2N as defined in timer_stm32h7xx.c. For CAMERA_CONTROL_PIN assignments, TIM3_CH3 (timer index 3) is the appropriate choice.Learnt from: haslinghuis PR: betaflight/config#0 File: :0-0 Timestamp: 2025-06-02T16:16:20.197Z Learning: In STM32F405-based flight controller configurations, timer pin mappings must be carefully analyzed for DMA stream conflicts, especially between motor timers, LED strip timers, and SPI DMA assignments. Changes to TIMER_PIN_MAPPING should include verification that all required peripherals (motors, LED strip, blackbox SPI) can coexist without DMA conflicts.Learnt from: haslinghuis PR: betaflight/config#835 File: configs/HDZERO_HALO_MPU6000/config.h:44-56 Timestamp: 2025-07-14T16:16:56.822Z Learning: For Betaflight board configurations of boards already in production, pin assignments in config.h files reflect the actual hardware design and cannot be changed, even if they present potential conflicts with debug interfaces. The configuration must match the physical board layout, not ideal software design preferences.
|
|
||
| #pragma once | ||
|
|
||
| #define FC_TARGET_MCU STM32G47X |
Contributor
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Confirm STM32G47X is a supported target macro
Please verify STM32G47X is recognized by Betaflight (timer/serial/DMA backends exist for G4xx). If not, builds will fail.
Run:
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Clone firmware to validate platform support
git clone --depth 1 https://github.com/betaflight/betaflight bf
echo "MCU macro presence:"
rg -n "STM32G47X" bf/src || true
echo "G4 platform files present:"
fd -t f "stm32g4" bf/src | sed 's|^| |'
echo "Timer backend includes PC13?"
rg -n "PC13" bf/src/platform/STM32/timer_stm32g4xx.c || true
echo "UART pins supported (PC10/PC11 for UART4)?"
rg -n "PC10|PC11|UART4|USART3" bf/src/platform/STM32/serial_uart_stm32g4xx.c || true
echo "I2C1 SCL on PA15 supported?"
rg -n "PA15|I2C1" bf/src/platform/STM32/bus_i2c_stm32g4xx.c || trueLength of output: 2882
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for FC_TARGET_MCU usage in entire BF repository
echo "FC_TARGET_MCU occurrences:"
rg -nC3 "FC_TARGET_MCU" bf || true
# List board-specific config.h files to inspect how targets are named
echo "Board config.h files:"
fd -t f "config.h" bf/src | sed 's|^| |'Length of output: 1007
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check supported G4 MCU macros in STM32G4.mk
grep -R "STM32G47" -n bf/src/platform/STM32/mk/STM32G4.mk || trueLength of output: 150
Use STM32G474xx as the target macro
Update FC_TARGET_MCU in configs/STARTFPVG473/config.h (line 25) from STM32G47X to STM32G474xx. Betaflight’s STM32G4.mk only defines STM32G474xx—STM32G47X isn’t recognized, so the build will fail.
🤖 Prompt for AI Agents
In configs/STARTFPVG473/config.h around line 25, the FC_TARGET_MCU macro is set
to STM32G47X which is not recognized by the build system; change the definition
to STM32G474xx so it matches Betaflight’s STM32G4.mk. Open
configs/STARTFPVG473/config.h, replace the current FC_TARGET_MCU value with
STM32G474xx, save the file, and re-run the build to confirm the issue is
resolved.
Comment on lines
+42
to
+47
| #define BEEPER_PIN PA8 | ||
| #define MOTOR1_PIN PB0 | ||
| #define MOTOR2_PIN PB1 | ||
| #define MOTOR3_PIN PB6 | ||
| #define MOTOR4_PIN PC13 | ||
| #define LED_STRIP_PIN PB2 |
Contributor
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Motor/LED/beeper pin sanity check
- MOTOR4_PIN is PC13, which on STM32 typically lacks timer PWM capability and has low drive strength; not suitable for motors.
- LED_STRIP_PIN PB2 requires a timer with DMA-capable channel; ensure TIMER_PIN_MAPPING provides a valid DMA channel for LED.
Please confirm the actual copper routing and intended timers for MOTOR4 and LED_STRIP. If MOTOR4 cannot stay on PC13, reassign to a valid timer pin before hardware freeze.
🏁 Script executed:
#!/bin/bash
# Locate timer mapping file
TIMER_FILE=$(fd timer_stm32f4xx.c | head -n1)
echo "Timer mapping file: $TIMER_FILE"
# Check for PC13 mapping (motor4)
echo "=== PC13 mappings ==="
rg -n "PC13" -C2 "$TIMER_FILE" || echo "No mapping for PC13 found"
# Check for PB2 mapping (LED strip)
echo "=== PB2 mappings ==="
rg -n "PB2" -C2 "$TIMER_FILE" || echo "No mapping for PB2 found"
# Show beginning of the STARTFPVG473 config
echo "=== STARTFPVG473/config.h (lines 1–100) ==="
sed -n '1,100p' configs/STARTFPVG473/config.h
# Look for timer pin mapping overrides in this config
echo "=== TIMER_PIN_MAPPING in STARTFPVG473/config.h ==="
rg -n "TIMER_PIN_MAPPING" -C2 configs/STARTFPVG473/config.hLength of output: 4550
🏁 Script executed:
#!/bin/bash
# Locate the STM32G4 timer mapping file
TIMER_FILE=$(fd timer_stm32g4xx.c | head -n1)
echo "Timer mapping file: $TIMER_FILE"
# Show DEF_TIM entries for PC13 and PB2 in the STM32G4 mapping
echo "=== DEF_TIM entries for PC13 in $TIMER_FILE ==="
grep -R "DEF_TIM.*PC13" "$TIMER_FILE" || echo "No DEF_TIM for PC13 found"
echo "=== DEF_TIM entries for PB2 in $TIMER_FILE ==="
grep -R "DEF_TIM.*PB2" "$TIMER_FILE" || echo "No DEF_TIM for PB2 found"
# Show the pin-to-timer map (timerPinMap) section
echo "=== timerPinMap array in $TIMER_FILE ==="
grep -R "timerPinMap" -n "$TIMER_FILE" -A5 -B2 || echo "timerPinMap array not found"
# Locate the macro definition for TIMER_PIN_MAP across the repo
echo "=== TIMER_PIN_MAP macro definition in repo ==="
grep -R "#define TIMER_PIN_MAP" -n .Length of output: 37631
🏁 Script executed:
#!/bin/bash
echo "Timer files in bf/src/platform/STM32:"
ls -1 bf/src/platform/STM32 | grep timer
echo "Searching DEF_TIM entries for PC13 in timer mapping files:"
grep -R "DEF_TIM.*PC13" bf/src/platform/STM32/timer*.c || echo "No mapping for PC13 found in any timer file"
echo "Searching DEF_TIM entries for PB2 in timer mapping files:"
grep -R "DEF_TIM.*PB2" bf/src/platform/STM32/timer*.c || echo "No mapping for PB2 found in any timer file"Length of output: 1427
Fix invalid TIMER_PIN_MAPPING for MOTOR4 and LED_STRIP
- MOTOR4_PIN PC13 isn’t on TIM3 – timer_stm32g4xx.c only defines PC13 for TIM1_CH1N and TIM8_CH4N, yet config uses
TIMER_PIN_MAP(4, PC13, 2, 5)(offset 2 → TIM3, ch 1N). Remap to a valid TIM1 or TIM8 channel (e.g.TIMER_PIN_MAP(4, PC13, 0, 5)for TIM1_CH1N) or choose a pin with TIM3_CHx support. - LED_STRIP_PIN PB2 isn’t on TIM2_CH1 – timer_stm32g4xx.c only defines PB2 for TIM5_CH1 and TIM20_CH1, yet config uses
TIMER_PIN_MAP(0, PB2, 1, 1)(offset 1 → TIM2, ch 1). UseTIMER_PIN_MAP(0, PB2, 3, 1)for TIM5_CH1 (with matching DMA_OPT) or the TIM20 entry.
🤖 Prompt for AI Agents
In configs/STARTFPVG473/config.h around lines 42–47, the TIMER_PIN_MAPPING
entries are invalid: PC13 (MOTOR4_PIN) is not mapped to TIM3 but to
TIM1_CH1N/TIM8_CH4N so change the TIMER_PIN_MAP for MOTOR4 to target TIM1 (use
offset 0 for TIM1_CH1N) or pick a pin actually on TIM3; PB2 (LED_STRIP_PIN) is
not TIM2_CH1 but TIM5_CH1/TIM20_CH1 so change the LED_STRIP TIMER_PIN_MAP to
target TIM5 (use offset 3 for TIM5_CH1) and update the DMA option to the
matching DMA_OPT for TIM5 (or pick the TIM20 mapping instead) to make the
pin/timer/channel combos valid.
Comment on lines
+76
to
+81
| #define TIMER_PIN_MAPPING \ | ||
| TIMER_PIN_MAP( 0, PB2, 1, 1 ) \ | ||
| TIMER_PIN_MAP( 1, PB0, 1, 2 ) \ | ||
| TIMER_PIN_MAP( 2, PB1, 1, 3 ) \ | ||
| TIMER_PIN_MAP( 3, PB6, 3, 4 ) \ | ||
| TIMER_PIN_MAP( 4, PC13, 2, 5 ) |
Contributor
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
TIMER_PIN_MAPPING contains invalid entries
- Channel “5” is invalid (timer channels are 1–4).
- PC13 generally has no timer channel; mapping it will fail.
- Numeric timer identifiers (1,2,3) must correspond to real TIMx instances with DMA support for DSHOT/LED.
Please correct the map using g4 backend references. As an example pattern (not a final proposal—use what your PCB supports):
#define TIMER_PIN_MAPPING \
/* LED_STRIP: pick a DMA-capable timer channel */ \
TIMER_PIN_MAP( 0, PB2, 3, 4 ) /* e.g., TIM3_CH4 for LED */ \
/* Motors on real timer channels */ \
TIMER_PIN_MAP( 1, PB0, 3, 3 ) /* TIM3_CH3 */ \
TIMER_PIN_MAP( 2, PB1, 3, 4 ) /* TIM3_CH4 */ \
TIMER_PIN_MAP( 3, PB6, 4, 1 ) /* TIM4_CH1 */ \
/* Replace PC13 with a valid pin, e.g., PC6 TIM8_CH1 if routed */ \
/* TIMER_PIN_MAP( 4, PC6, 8, 1 ) */Use serial_uart_stm32g4xx.c and timer_stm32g4xx.c as the source of truth.
🏁 Script executed:
#!/bin/bash
# Locate the STARTFPVG473 board config header
fd STARTFPVG473/config.hLength of output: 26
🏁 Script executed:
#!/bin/bash
# Find directory or files related to STARTFPVG473
fd -t f -I STARTFPVG473 || true
# Locate any headers mentioning STARTFPVG473
rg -l STARTFPVG473 -g '*.h' || true
# Check TIMER_PIN_MAPPING definitions across configs for similar patterns
rg -n "TIMER_PIN_MAPPING" -g 'configs/**' || trueLength of output: 35339
🏁 Script executed:
#!/bin/bash
sed -n '60,100p' configs/STARTFPVG473/config.hLength of output: 1174
🏁 Script executed:
#!/bin/bash
# Show initial config including TIMER_PIN_MAPPING
sed -n '1,100p' configs/STARTFPVG473/config.h
# Locate the STM32 G4 timer implementation
fd src/platform/STM32/timer_stm32g4xx.c
# Display the timer pin definitions and mapping function
sed -n '1,200p' src/platform/STM32/timer_stm32g4xx.c
# Check for any mapping entries for PC13
grep -R "PC13" -n src/platform/STM32/timer_stm32g4xx.c || trueLength of output: 3024
🏁 Script executed:
#!/bin/bash
# List STM32 platform directories
fd -t d -I 'STM32*' src/platform
# Find any G4 timer implementation files
fd -t f -I 'timer_stm32g4*' .Length of output: 208
🏁 Script executed:
#!/bin/bash
# View first 200 lines of the G4 timer implementation
sed -n '1,200p' bf/src/platform/STM32/timer_stm32g4xx.c
# List all DEF_TIM mappings
grep -R "DEF_TIM" -n bf/src/platform/STM32/timer_stm32g4xx.c
# Check for any PC13 entries
grep -R "PC13" -n bf/src/platform/STM32/timer_stm32g4xx.c || trueLength of output: 10841
Fix TIMER_PIN_MAPPING timer instances and pin support
- PB2 (LED_STRIP_PIN) uses timer index 1 (TIM2) but PB2 only has TIM5 (index 4) or TIM20 (index 11) channels.
- PB0/PB1 (MOTOR1_PIN/MOTOR2_PIN) are mapped to TIM2 (1) but these pins are on TIM3 (2) or complementary TIM8 (7) channels.
- PC13 (MOTOR4_PIN) is assigned to TIM3 (2) but PC13 only supports TIM1_CH1N (0) or TIM8_CH4N (7) and isn’t valid for standard PWM—choose a different pin or timer.
- The fourth parameter is the DMA option, not a timer channel; run
dma pin <pin> <dma>or usetimer mapin CLI to determine the correct DMA_OPT for each entry.
🤖 Prompt for AI Agents
In configs/STARTFPVG473/config.h around lines 76–81, the TIMER_PIN_MAPPING
entries use incorrect timer indices and misuse the fourth field (it's DMA
option, not channel). Update PB2's timer index to a valid timer that actually
drives PB2 (e.g., TIM5 index 4 or TIM20 index 11) instead of 1; update PB0/PB1
to a timer that supports those pins (e.g., TIM3 index 2 or TIM8 index 7) rather
than 1; remove or replace PC13 mapping because PC13 does not support standard
PWM (pick a valid PWM-capable pin instead); and replace each fourth parameter
with the correct DMA_OPT value (obtain correct DMA options by running the CLI
commands `timer map` to verify timer↔pin mappings and `dma pin <pin> <dma>` or
`dma pin <pin> <dma>` help to determine the right DMA_OPT) so the entries use
the correct timer index and DMA option for each pin.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull-Request requirements
Mandatory Review for All New Flight Controllers
Hardware Compliance Requirements
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
master.Checklist (✓/✕, or y/n)
Summary by CodeRabbit