Support for 3DR Control N1 board

[TOTON95]

Summary

Add initial board support for the 3DR Control N1, a compact STM32H743-based flight controller launched by 3DR.

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Description

The 3DR Control N1 is a miniature flight controller (17.6 × 28 mm, 2.7 g) designed for size-constrained builds. It uses the STM32H743, running at up to 480 MHz, with dual IMUs for redundancy and a 1 MB page EEPROM for parameter storage.

Hardware:

• MCU: STM32H743 (Cortex-M7, 480 MHz)
• IMU: 2× IIM42653 (SPI1, SPI2)
• Baro: DPS368 (SPI6)
• Compass: AK09940A (I2C1)
• Storage: 1 MB M95P08 Page EEPROM (SPI6)
• 12× PWM outputs (BidirDShot capable), TIM1/TIM2/TIM4
• 7× UARTs (3× with hardware flow control)
• 2× FDCAN
• USB: USB1_OTG_HS in FS mode (PB14/PB15)
• MicroSD via SDMMC1
• WS2812B addressable LED

Hardware testing checklist:

• Firmware upload via USB
• Bootloader LED blink and USB enumeration
• Parameter save/load
• Both IMUs functional and aligned
• Compass functional
• Barometer functional
• CAN bus
• PWM outputs (DShot)
• All UARTs
• SD card read/write
• Battery voltage and current sensing

[Hwurzburg]

this needs to be three different PRs, IMO....one for the new compass, one for the change to Storage, and then a new board hwdef.... allows reviews by those adept in each area

[TOTON95]

Hello @Hwurzburg, so should I close this one and split it in those 3 different PRs or should I keep this one open and force push what is relevant for the board itself, then move the other commits to their respective PRs?

[Hwurzburg]

I would keep this one open for the board...and move the compass and storage to different PRs...note that this one is dependent on the other two...

[TOTON95]

Hi @Hwurzburg, thanks for the feedback. The PR has been split as suggested:

• AP_Compass: add support for AK09940A magnetometer #33445: AK09940A magnetometer driver
• AP_PageEEPROM: add initial support for SPI Page-EEPROM storage #33446: AP_PageEEPROM initial support

This PR (#33427) will be rebased on top of both once they are approved and merged.

[andyp1per]

Automated hwdef review (/hwdef-check)

PR 33427 · base master · new board 3DRControlN1

This PR is much larger than a board addition - it also introduces the AP_PageEEPROM library, the AP_Compass_AK09940A driver, AP_HAL Storage integration, an OTG-detection fix, and a chibios_hwdef.py change for STM32_OTGHS_AS_OTG1. This automated pass only validates the board definition; the library, driver, and HAL changes are out of scope here and need a proper code review (human or /code-review).

Build

• ./waf configure --board 3DRControlN1: pass

Must-fix

• HAL_BAT_VOLT_PIN 18 (hwdef.inc:197) is a typo - the macro is HAL_BATT_VOLT_PIN (two T's). It exists nowhere else in the tree, and the generated build/3DRControlN1/hwdef.h emits no HAL_BATT_VOLT_PIN, so analog battery voltage on PA4 is never configured. Change it to HAL_BATT_VOLT_PIN 18.

Should-fix

• Battery scales are inconsistent and incomplete. The hwdef sets HAL_BATT_CURR_SCALE 17 and no HAL_BATT_VOLT_SCALE, but the README's recommended power module wants BATT_VOLT_MULT 15.3 and BATT_AMP_PERVLT 50.0. Decide whether the board ships with a default module (then set both scales to match the README) or leaves it to the user (then drop the hard-coded current scale), and reconcile the two.
• Onboard compass: README says "the internal compass is disabled by default", but the hwdef has an active COMPASS AK09940A I2C:0:0x0C true ROTATION_NONE plus AP_COMPASS_PROBING_ENABLED 1, i.e. it is enabled (as external). Either actually disable it or fix the README.
• Baro naming is inconsistent: SPIDEV dps310, BARO DPS280 SPI:dps310, the comment says "DPS368", and the README says "DPS368". The DPS280 driver does cover the DPS3xx family, so it works, but align the names to the populated part.
• Trailing whitespace in hwdef.inc (lines 84, 96, 101, 129, 137, 162). git diff --check flags all of them.
• STDOUT_SERIAL SD7 / STDOUT_BAUDRATE 115200 (hwdef.inc:46-47) redirect debug stdout to UART7 and sit oddly inside the UART4 block. If this is a bring-up convenience, drop it for release; otherwise confirm it is intended.
• defaults.parm sets NTF_LED_LEN 1, which §7.6 lists as a user LED preference rather than a board default. The board does have a single onboard LED, so it is defensible, but worth a second look.

Notes

• System timer: the default TIM5 is correct here - TIM5 is not used for PWM (motors are on TIM1/TIM2/TIM4, LED on TIM3), so no override or CH_CFG_ST_RESOLUTION is needed.
• BIDIR DShot is applied correctly: one channel per CH1/CH2 and CH3/CH4 pair on TIM1/TIM2/TIM4, and nothing on TIM4_CH4 (which must never be BIDIR). Nicely done.
• Board ID AP_HW_3DRControlN1 (1186) is already registered and USB_PRODUCT 0x1186 matches; the PR correctly does not touch board_types.txt, so no AP_Bootloader: commit is needed (the helper's note there is a false positive). Commit split (bootloaders / AP_HAL_ChibiOS / AP_PageEEPROM / AP_Compass / AP_HAL / Tools) is clean.
• The README UART table uses non-ASCII check glyphs (✔/✘); harmless in rendered markdown but ArduPilot READMEs usually stick to ASCII.

_{Generated by Claude via /hwdef-check. Not a substitute for a human review pass.}

[andyp1per]

See comment