Add target ACCTONGFH7(STM32H743)

[BrianChang1212]

Add support for the new flight controller: ACCTONGFH7

Hardware Specifications

• MCU: STM32H743
• Board identifier: GFH7
• Gyro/Accelerometer: ICM42605 and LSM6DSK320X
• Barometer: DPS310
• Compass: IST8310
• OSD: MAX7456
• Motor Outputs: 8
• UARTs: 8
• Blackbox: SD card
• HSE: 16 MHz

Build command:

• cmake --build build-acctongfh7 --target ACCTONGFH7

[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 ACCTONGFH7 STM32H743 flight controller target

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Adds an ACCTONGFH7 build target for STM32H743 hardware with a 16 MHz oscillator.
• Maps dual IMUs, sensors, OSD, SD storage, eight motor outputs, and board peripherals.
• Sets default serial roles, CRSF receiver, sensor alignment, and 12V rail control.

Diagram

graph TD
  Build["CMake target"] --> Target["GFH7 definition"] --> MCU["STM32H743 MCU"] --> Buses["SPI and I2C"] --> Devices["Sensors and OSD"]
  MCU --> Serial["VCP and UARTs"]
  MCU --> Timers["PWM timers"] --> Outputs["Motors and LED"]
  MCU --> Storage["SDIO storage"]

Loading

High-Level Assessment

The PR follows INAV's established target structure: CMake selects the MCU, target.h declares hardware capabilities, target.c registers devices and timers, and config.c applies runtime defaults. A generic board-description abstraction would add inconsistency and scope without improving this single-board integration.

Files changed (4) +288 / -0

Enhancement (3) +287 / -0

config.cDefine ACCTONGFH7 runtime defaults +46/-0

Define ACCTONGFH7 runtime defaults

• Assigns default ESC serial, GPS, and serial receiver functions. It also configures USER1 power control, selects the LSM6DSK320X as the preferred IMU, and aligns the compass.

src/main/target/ACCTONGFH7/config.c

target.cRegister onboard IMUs and timer outputs +46/-0

Register onboard IMUs and timer outputs

• Registers the ICM42605 and LSM6DSK320X SPI hardware descriptors. Maps TIM1 and TIM8 to eight motor outputs and TIM2 to the LED strip while avoiding the ADC1 DMA reservation.

src/main/target/ACCTONGFH7/target.c

target.hDeclare ACCTONGFH7 hardware capabilities and pin mappings +195/-0

Declare ACCTONGFH7 hardware capabilities and pin mappings

• Defines the GFH7 board identity and mappings for LEDs, beeper, buses, sensors, OSD, serial ports, SDIO, ADC, PINIO, and output features. Enables CRSF reception, DShot, ESC support, default telemetry and blackbox features, and eight PWM outputs.

src/main/target/ACCTONGFH7/target.h

Other (1) +1 / -0

CMakeLists.txtRegister the ACCTONGFH7 STM32H743 build target +1/-0

Register the ACCTONGFH7 STM32H743 build target

• Adds the ACCTONGFH7 firmware target for an STM32H743XI using a 16 MHz external oscillator.

src/main/target/ACCTONGFH7/CMakeLists.txt

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

Code Review by Qodo

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

1. A board comment denies active support 🐞 Bug ⚙ Maintainability

Description

The CAN section says its definitions are unreferenced documentation even though USE_DRONECAN,
CAN1_RX, and CAN1_TX enable the compiled DroneCAN implementation. On every boot this
configuration initializes FDCAN1, claims PD0 and PD1, enables its interrupt, and schedules periodic
DroneCAN processing, so maintainers are given the opposite of the target's actual behavior.

Code

src/main/target/ACCTONGFH7/target.h[R139-140]

+// TLE9251VLE transceiver is wired to PD0/PD1. INAV has no CAN/DroneCAN stack
+// yet - these defines are unreferenced and kept only as hardware documentation.

Evidence

The target defines DroneCAN and its pins, while startup and task code consume that guard and the H7
driver configures the pins for FDCAN1. These references directly disprove the claim that the
definitions are unreferenced or that no stack exists.

src/main/target/ACCTONGFH7/target.h[138-143]
src/main/fc/fc_init.c[579-582]
src/main/fc/fc_tasks.c[512-516]
src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[288-296]

Agent prompt

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

## Issue description
The ACCTONGFH7 CAN comment says the definitions are unreferenced hardware documentation, but `USE_DRONECAN` activates initialization, pin ownership, interrupts, and scheduled DroneCAN processing.

## Fix Focus Areas
- src/main/target/ACCTONGFH7/target.h[139-143]

## Recommended Fix
Replace the comment with an accurate description that the TLE9251VLE transceiver on PD0/PD1 provides active DroneCAN support.

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

---

Context sources

Review mode: ⚖️ Balanced: This adds a new hardware target with board-wide pin mappings, peripherals, timers, sensors, storage, and runtime defaults, creating meaningful correctness and build risks across several configuration paths.

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 ↗

Previous reviews

Review updated until commit aab6d05 ⚖️ Balanced

Results up to commit 5bb13da

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

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

1. A board comment denies active support 🐞 Bug ⚙ Maintainability

The CAN section says its definitions are unreferenced documentation even though USE_DRONECAN,
CAN1_RX, and CAN1_TX enable the compiled DroneCAN implementation. On every boot this
configuration initializes FDCAN1, claims PD0 and PD1, enables its interrupt, and schedules periodic
DroneCAN processing, so maintainers are given the opposite of the target's actual behavior.

Agent Prompt

## Issue description
The ACCTONGFH7 CAN comment says the definitions are unreferenced hardware documentation, but `USE_DRONECAN` activates initialization, pin ownership, interrupts, and scheduled DroneCAN processing.

## Fix Focus Areas
- src/main/target/ACCTONGFH7/target.h[139-143]

## Recommended Fix
Replace the comment with an accurate description that the TLE9251VLE transceiver on PD0/PD1 provides active DroneCAN support.

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

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

Code review by qodo was updated up to the latest commit aab6d05

[BrianChang1212]

Superseded by #11993, which uses the correctly named feature/acctongfh7-board-support-10x branch and targets maintenance-10.x.