feat(boards): add DAKEFPV H743, H743 Pro and H743 Slim flight controllers by mor2code · Pull Request #27522 · PX4/PX4-Autopilot

mor2code · 2026-05-30T01:19:32Z

Summary

Adds board support for the DAKEFPV H743 family of flight controllers (STM32H743):

dakefpv_h743 — base variant
dakefpv_h743pro — adds a CAN/UAVCAN interface
dakefpv_h743slim — adds CAN/UAVCAN, reduced sensor/param set, PA4 battery sensing

Highlights

2× ICM-42688P IMUs (SPI1 ROLL_180, SPI4 PITCH_180), SPL06 barometer on I2C2
Onboard Micron N25Q128 SPI NOR flash mounted via littlefs for logging; rc.board_extras seeds /fs/microsd/etc/extras.txt for user startup commands
All 8 UARTs exposed as PX4 ports (GPS1, TELEM1–4, RC, GPS2); UART DMA prioritized to the always-active links (GPS1, TELEM3, RC, TELEM4), debug console left interrupt-driven
Digital FPV camera support via MSP DisplayPort OSD (CONFIG_DRIVERS_OSD_MSP_OSD), defaulted to TELEM3 (MSP_OSD_CONFIG=103)

NuttX submodule change (please read)

This PR pins the NuttX submodule to bdb949ee. The onboard flash is a Micron N25Q128 (JEDEC 0x20/0xBA), which requires the Micron/N25Q "type‑D" detection in drivers/mtd/w25.c. That support is present in bdb949ee (an upstream PX4/NuttX commit) but is not in PX4 main's currently‑referenced NuttX — without this pin, all littlefs file writes fail on the board (verified on hardware: file create returns ENOENT). Happy to coordinate landing N25Q128 support in main's NuttX so this submodule pin can be dropped.

Testing

All three default targets build (dakefpv_h743_default, dakefpv_h743pro_default, dakefpv_h743slim_default)
Verified on hardware: firmware flashes and boots, littlefs read/write works, extras.txt seeds, compass detected on I2C2

github-actions · 2026-05-30T01:34:31Z

🔎 FLASH Analysis

px4_fmu-v5x [Total VM Diff: 0 byte (0 %)]

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%     +55  [ = ]       0    .debug_abbrev
  -0.0%      -2  [ = ]       0    .debug_info
  -0.0%      -5  [ = ]       0    .debug_line
     +40%      +2  [ = ]       0    [Unmapped]
    -0.0%      -7  [ = ]       0    [section .debug_line]
  +0.0%     +48  [ = ]       0    TOTAL

px4_fmu-v6x [Total VM Diff: 0 byte (0 %)]

    FILE SIZE        VM SIZE    
 --------------  -------------- 
  +0.0%     +55  [ = ]       0    .debug_abbrev
  -0.0%      -2  [ = ]       0    .debug_info
  -0.0%      -5  [ = ]       0    .debug_line
    +100%      +2  [ = ]       0    [Unmapped]
    -0.0%      -7  [ = ]       0    [section .debug_line]
  +0.0%     +48  [ = ]       0    TOTAL

Updated: 2026-08-29T19:03:58

github-actions · 2026-05-30T01:41:48Z

No broken links found in changed files.

mor2code · 2026-06-05T18:46:27Z

Friendly bump 🙂 This PR (new DAKEFPV H743 / Pro / Slim flight controllers) has been open since May 30 with all CI green and no review yet. @dirksavage88 — since you reviewed the comparable 3DR Control N1 board PR (#27395), would you be able to take a look, or point me to the right reviewer? Happy to address any feedback. Thanks!

farhangnaderi · 2026-06-05T18:56:47Z

I have this on my to-do list.
This weekend I can go over it.

farhangnaderi · 2026-06-06T01:37:53Z

@mor2code:

Board additions require at least one flight log linked from https://logs.px4.io/ showing basic operation on PX4 main.
NuttX submodule bump needs a separate PR standalone NuttX-bump PR first, then rebase this PR on top of it.
However if it was me I would split this PR into 3 for each board.

farhangnaderi

The rest will be on @dirksavage88 and @hamishwillee .

farhangnaderi · 2026-06-06T01:39:05Z

+#------------------------------------------------------------------------------
+
+# FC board is mounted with IMU facing down — apply ROLL_180 correction
+param set-default SENS_BOARD_ROT 8


You are rotating your IMU twice? You rotated again in the board start.
Same review applies to H743 Pro (identical sensor init). H743 Slim's rc.board_sensors uses YAW_180 and YAW_270 for its IMUs and does not set SENS_BOARD_ROT, which looks correct.

Good catch — SENS_BOARD_ROT 8 was redundant with the per-IMU -R 8/-R 12 rotations already applied in rc.board_sensors (exactly how H743 Slim does it correctly, without setting SENS_BOARD_ROT). Removed SENS_BOARD_ROT from both H743 and H743 Pro rc.board_defaults; per-sensor rotation is now the single source of truth for IMU orientation. Fixed in f367e08742.

farhangnaderi · 2026-06-06T01:40:11Z

+ *
+ ****************************************************************************/
+
+/* The Durandal-v1 uses an STM32H743II has 2048Kb of main FLASH memory.


This is copied from the Durandal template. The DAKEFPV boards use STM32H743VI (LQFP100) I assume? not the H743II (BGA176)? The comment should be updated.

Confirmed — copy-paste leftover from the Durandal template. DAKEFPV boards use STM32H743VI (LQFP100), not H743II (BGA176) / H743ZI. Updated the comment to name the correct board/chip and generalized the BOOT0 description (dropped the Durandal-specific switch claim, since I can't confirm DAKEFPV has the same physical strap). Fixed in 9c4547a98c (covers all three variants).

farhangnaderi · 2026-06-06T01:40:26Z

+ *
+ ****************************************************************************/
+
+/* The Durandal-v1 uses an STM32H743II has 2048Kb of main FLASH memory.


Same fix applied here — see 9c4547a98c, which corrects the comment in all three variants (H743, H743 Pro, H743 Slim).

farhangnaderi · 2026-06-06T01:40:36Z

+ *
+ ****************************************************************************/
+
+/* The Durandal-v1 uses an STM32H743II has 2048Kb of main FLASH memory.


Same fix applied here too — see 9c4547a98c, which corrects the comment in all three variants (H743, H743 Pro, H743 Slim).

farhangnaderi · 2026-06-06T01:41:46Z

+| R1, T1       | UART1 RX/TX                                                              | GPS                 |
+| R2, T2       | UART2 RX/TX                                                              | TELEM1              |
+| R3, T3       | UART3 RX/TX                                                              | TELEM2              |
+| R4, T4       | UART4 RX/TX (PB8/PB9)                                                   | Available           |


default.px4board sets CONFIG_BOARD_SERIAL_TEL3="/dev/ttyS3" (which is UART4). UART4 is TELEM3 by default, not "Available." ???????

You're right — same class of error already fixed for the base H743 doc in ea14c91b14. Corrected the table: UART4 (ttyS3) → TELEM3, USART6 (ttyS5) → TELEM4, UART7 (ttyS6) → System console, UART8 (ttyS7) → GPS2. Fixed in 0e97cc13b8.

farhangnaderi · 2026-06-06T01:42:53Z

+CONFIG_START_MONTH=11
+CONFIG_STDIO_BUFFER_SIZE=256
+CONFIG_STM32H7_ADC1=y
+CONFIG_STM32H7_ADC3=y


You are wasting Flash here. I cant see ADC3 in your board_config.h??

Confirmed — board_config.h only references ADC1 (ADC1_CH, on the shared ADC123/ADC12 pins used for Vbat/current/RSSI); ADC3 is never started or referenced anywhere on these boards. It was enabled in all three variants' defconfigs, not just H743 — removed CONFIG_STM32H7_ADC3=y from all of them. Fixed in a1fb1405db.

Reopening this one — I have to walk back my earlier "confirmed", because I checked board_config.h and stopped there. ADC3 is used on these boards, just not from any board file.

board_adc adds the MCU temperature sensor to its channel list unconditionally:

// src/drivers/adc/board_adc/ADC.cpp:51 channels |= px4_arch_adc_temp_sensor_mask();

On STM32H7 that channel is 20, and it lives on ADC3, so the sample path redirects it:

// platforms/nuttx/src/px4/stm/stm32h7/adc/adc.cpp if (channel == PX4_ADC_INTERNAL_TEMP_SENSOR_CHANNEL) { channel = ADC3_INTERNAL_TEMP_SENSOR_CHANNEL; base_address = STM32_ADC3_BASE;

With CONFIG_STM32H7_ADC3 unset the peripheral has no clock, EOC never asserts, and every conversion burns the full 50 µs timeout inside a critical section before returning UINT32_MAX. At board_adc's 100 Hz that floods the console:

ERROR [board_adc] sample timeout

I counted 124 of them in a single dmesg on H743 Pro. The H7 ADC driver assumes ADC3 is present, too — it force-bumps SYSTEM_ADC_COUNT to 2 when a board declares a single non-ADC3 instance, specifically to leave room for the temperature sensor.

On the flash cost: I should have measured rather than agreed. CONFIG_STM32H7_ADC3 gates exactly one statement — regval |= RCC_AHB4ENR_ADC3EN in stm32h7x3xx_rcc.c — which disappears into existing alignment padding. Measured before and after, all three variants:

board before after delta

h743 1628356 B (88.74%) 1628356 B (88.74%) 0

h743pro 1769256 B (96.42%) 1769256 B (96.42%) 0

h743slim 1755808 B (95.68%) 1755808 B (95.68%) 0

Byte-identical. Verified on H743 Pro hardware: the sample timeout count goes 124 → 0, with battery voltage, current and RSSI unaffected on ADC1.

Every other in-tree H7 board (holybro/kakuteh7, matek/h743-slim, ark/fmu-v6x, holybro/durandal-v1, …) enables both ADC1 and ADC3 for this reason.

So I've restored it. Your underlying point was right — an unused peripheral shouldn't be enabled — it just turned out not to be unused, and the dependency is invisible from the board files, which is how we both missed it. Happy to drop it again if you'd rather these boards forgo the die-temperature reading.

mor2code · 2026-06-07T03:15:18Z

Thanks for the review, @farhangnaderi — appreciate you taking the time.

Flight log: I'll review my flight logs and post a link from logs.px4.io showing basic operation on PX4 main by the end of this week.
NuttX submodule bump: agreed — already split out as a standalone PR: mtd/w25: add Micron N25Q128 JEDEC manufacturer and memory type support NuttX#377 ("mtd/w25: add Micron N25Q128 JEDEC manufacturer and memory type support"), green and mergeable. Once that lands I'll rebase this PR's submodule pin on the merged commit so it's no longer a fork-specific reference.
Splitting into 3 PRs: I'd like to make a case for keeping this as a single PR if that's alright — H743, H743 Pro and H743 Slim are close siblings that share the bulk of their board-support code and config (sensor init, DMA map, bootloader script, defconfig, etc.), so reviewing them together avoids a lot of duplicated effort across near-identical diffs. Happy to revisit if you'd still rather see them separated, but wanted to lay out the reasoning first.

I've also pushed fixes for the four inline issues you flagged — replies on each thread below.

rc.board_defaults set SENS_BOARD_ROT 8 (ROLL_180) on top of the per-IMU -R 8 / -R 12 rotations already passed to icm42688p in rc.board_sensors, double-applying the orientation correction (flagged in PR review: PX4#27522). H743 Slim does this correctly — per-sensor -R only, SENS_BOARD_ROT left at its default — so bring H743 and H743 Pro in line with it.

The introductory comment block was copied from the Durandal-v1 template and referenced the wrong silicon (STM32H743II / H743ZI, BGA176/LQFP144) and a Durandal-specific BOOT0 switch (flagged in PR review: PX4#27522). DAKEFPV H743/Pro/Slim use STM32H743VI (LQFP100, per nuttx-config defconfig CONFIG_ARCH_CHIP_STM32H743VI). Update the comment to name the correct board/chip and generalize the BOOT0 description to the documented STM32H7 strap behaviour rather than asserting unverified Durandal-specific hardware.

Same class of mislabeling already corrected for the base H743 doc in ea14c91b14 (flagged in PR review: PX4#27522). Per default.px4board / board_dma_map.h: UART4 (ttyS3) is TELEM3, USART6 (ttyS5) is TELEM4, UART7 (ttyS6) is the system console, and UART8 (ttyS7) is GPS2 — not "Available" / "TELEM3" / "TELEM4" / "Available" as the table previously read.

Per review on PX4#27522, the NuttX board.h files for all three DAKEFPV variants still carried a 2024 copyright year left over from the original template, while the rest of the board-specific files were already bumped to 2026 (the actual contribution year). Signed-off-by: Nir Mor <nir.mor@gmail.com>

… priority I2C2 carries the onboard SPL06 baro and is also wired out to the external magnetometer connector, so the bus itself must be marked external (px4_i2c_buses) for the optional external compass to be auto-detected, and the baro is started with `-X -b 2` to match. That left px4_i2c_device_external() classifying the onboard baro as external too, which affects its calibration priority versus a future external baro. Override it per-device, the same pattern already used by boards/px4/fmu-v6c for its shared internal/external I2C bus: the bus stays external for the magnetometer, but the SPL06's own device ID is reported back as internal. Addresses review on PX4#27522. Signed-off-by: Nir Mor <nir.mor@gmail.com>

The onboard Micron N25Q128 SPI NOR was driven by the w25 MTD driver, which does not recognise the Micron JEDEC ID and so required a downstream NuttX patch (and submodule pin) to mount littlefs. NuttX's m25p driver already supports the Micron MT25Q/N25Q family natively (manufacturer 0x20, memory type 0xBA/0xBB, capacity 0x18) over plain SPI, so switch h743 and h743pro to it. Enable M25P_SUBSECTOR_ERASE to keep the 4 KB erase granularity littlefs used with w25. This removes the need for any NuttX source change, allowing the board to build on upstream NuttX without the submodule pin. h743slim has no onboard dataflash and is unaffected. Signed-off-by: Nir Mor <nir.mor@gmail.com>

Both boards use TIM5 for the high resolution timer (HRT_TIMER 5), and the UAVCAN stm32h7 driver defaults to TIM5 as well. With UAVCAN enabled the driver took the timer over and the HRT stopped serving scheduled work items: uavcan itself never ran (0 Hz against a 3 ms interval), cdcacm_autostart executed exactly once and was never rescheduled, so /dev/ttyACM0 could not be opened (ENOTCONN) and USB never came up. Interrupt driven work (IMUs, EKF2) kept running, which made the board look healthy while USB was dead. Point UAVCAN at TIM7, which is free on both boards; TIM2 (the override other H7 boards use) drives DShot outputs here. Verified on H743 Pro hardware: with UAVCAN enabled, uavcan now runs at 332 Hz, cdcacm_autostart reaches connected/mavlink, and the host receives MAVLink over USB. Signed-off-by: Nir Mor <nir.mor@gmail.com>

The pads are silkscreened by UART number, so T4/R4 is UART4 - which PX4 exposes as TELEM3, not TELEM4. Reading the label as TELEM4 leads to MSP_OSD_CONFIG 104 and a digital VTX that never receives DisplayPort. Add the board pad labels to the serial port tables, warn about the mismatch, and document the OSD setup on all three variants: the AT7456E analog OSD runs alongside the digital HD OSD, and the digital VTX connects to T4/R4 per the wiring diagram, matching the MSP_OSD_CONFIG 103 default. Signed-off-by: Nir Mor <nir.mor@gmail.com>

TELEM4 is a free port with no assigned function; suggesting it as a digital VTX destination only invites the TELEM3/TELEM4 mix-up the note is there to prevent. Document the wired port only. Signed-off-by: Nir Mor <nir.mor@gmail.com>

mavlink_main.cpp now requires it for its recursive per-channel send mutex and fails the build with an #error otherwise. Other boards (px4/fmu-v6x, matek/h743-mini) already set it. Signed-off-by: Nir Mor <nir.mor@gmail.com>

The board startup scripts ran "atxxxx start -s" unconditionally. Starting the driver at boot prevents the USB CDC interface from enumerating on the H743 Pro: the board disappears from USB entirely and can only be recovered by re-flashing through the bootloader. This was reproduced deterministically by toggling only OSD_ATXXXX_CFG between 0 and 2 with the start command left in place. OSD_ATXXXX_CFG selects the video standard and defaults to 0 (disabled), so the driver was being force-started in a state upstream treats as opt-in. holybro/kakuteh7-wing, the only in-tree board shipping this driver, guards the start behind the same parameter; do the same here. On h743 and h743slim the start command was doubly wrong: the driver was not compiled in at all, so the line failed on every boot. Enable the driver on all three variants, which all carry the AT7456E, so the guarded start can work once the underlying driver problem is resolved. The OSD remains disabled by default and is documented as such, with a warning that enabling it is untested and currently breaks USB. Signed-off-by: Nir Mor <nir.mor@gmail.com>

Starting the atxxxx driver from rc.board_sensors prevents the USB CDC interface from coming up on the H743 Pro: the board does not enumerate at all and can only be recovered by re-flashing through the bootloader. rc.board_sensors runs during sensor bring-up, before USB is available. Nearly every in-tree board carrying this chip - omnibus/f4sd, which the driver was written for, holybro/kakuteh7, radiolink/PIX6 and others - starts it from rc.board_extras instead, which runs once the system is up. holybro/kakuteh7-wing is the exception, and it was the wrong model to copy. Move the guarded start to rc.board_extras, matching the upstream form verbatim, and add the file for h743slim which did not have one. With the driver started from rc.board_extras the board boots normally with the OSD enabled, so enable it by default. OSD_ATXXXX_CFG selects the video standard and is set to 2 (PAL); NTSC users set it to 1 and it can be turned off with 0. Verified on H743 Pro hardware: healthy boot and a full MAVLink stream with the OSD enabled. Video output itself is not verified, as that needs an analog camera and monitor. The h743 and h743slim changes are build-verified only. Signed-off-by: Nir Mor <nir.mor@gmail.com>

…cripts The H743 Pro and H743 Slim bootloader linker scripts both described themselves as "The DAKEFPV H743", a copy-paste leftover from the base variant. Chip and memory layout are identical across the three boards, so this is comment-only. Signed-off-by: Nir Mor <nir.mor@gmail.com>

…43 Pro The rotations were transcribed verbatim from ArduPilot's hwdef (ROLL_180 / PITCH_180). ArduPilot's Invensensev3 driver publishes the chip's native frame, but PX4's icm42688p driver already flips Y/Z into a z-down frame, so the PX4 rotation is the ArduPilot one composed with ROLL_180: none for the SPI1 IMU and YAW_180 for the SPI4 IMU. Verified on an H743 Pro against the accel gravity vector: the board only read correctly with an extra ROLL_180 (SENS_BOARD_ROT=8) on top of the old -R 8 / -R 12, which is exactly this correction. Folding it into the per-sensor -R flags keeps SENS_BOARD_ROT free for the vehicle mounting orientation. The non-Pro H743 shares the same IMU placement (ArduPilot's DAKEFPVH743 hwdef includes the Pro one). Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

Same transcription error as the one fixed for H743/H743 Pro. ArduPilot's DAKEFPVH743_SLIM hwdef lists ROTATION_YAW_180 / ROTATION_YAW_270 for the two ICM-42688Ps, and those values were copied straight across. PX4's icm42688p driver already flips Y/Z into a z-down frame, so the PX4 rotation is the ArduPilot one composed with ROLL_180: SPI1: YAW_180 * ROLL_180 = PITCH_180 (was YAW_180, now 12) SPI4: YAW_270 * ROLL_180 = ROLL_180_YAW_270 (already 14, comment fixed) The SPI4 value was right by accident but labelled "YAW_270", which is rotation 6, not 14. Both comments now name the rotation they set. The composition was checked numerically against the rot_lookup table in src/lib/conversion/rotation.h, and reproduces the H743 Pro values that were verified on hardware against the accel gravity vector. Unlike the H743/H743 Pro change, this one is derived rather than measured: no H743 Slim was available to confirm it on the bench. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

GPIO_SPI2_SCK selected GPIO_SPI2_SCK_3, which is PB10 -- the same pin as GPIO_I2C2_SCL. Bringing up the AT7456E OSD reconfigured PB10 from AF4 (I2C) to AF5 (SPI), taking the clock line away from the internal SPL06 barometer bus. The bus then stayed dead until reboot, because NuttX's stm32_i2c_reset() failure path skips stm32_i2c_init() and leaves the peripheral clock-gated with its interrupts detached. The symptom was easy to misread: i2cdetect appeared to hang, but it was only scanning an already-dead bus, and its retry loop hammered I2C_RESET until the board froze. The barometer had in fact stopped a few hundred milliseconds into boot -- rc.board_sensors starts spl06, it gets a handful of samples, then rc.board_extras starts atxxxx and the bus dies. The /* PB13 */ comment on the line was right all along; only the macro was wrong. GPIO_SPI2_SCK_4 is PB13. This affects all three variants, and the OSD is enabled by default (OSD_ATXXXX_CFG=2 in rc.board_defaults), so an out-of-the-box board lost its barometer. Verified on H743 Pro hardware: before: spl06 4 samples / 685 comms errors, i2cdetect froze the board after: spl06 1802 samples / 0 comms errors, i2cdetect completes a full scan and finds 0x76, with atxxxx running on SPI2 concurrently H743 and H743 Slim compile clean but were not flashed; the pin change is identical on all three and the Slim's other SPI2 pins (PC2/PC3) already matched their macros. Assisted-by: Claude:claude-opus-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

…eeds ADC3 was dropped twice as unused - 3ca1e49 (at a reviewer's request on PX4#27522, to save flash) and d0628dd7c0. Both read board_config.h, which only declares ADC1 channels for battery voltage, battery current and RSSI, and concluded ADC3 is never referenced. It is referenced, just not from the board files. board_adc adds the MCU temperature sensor to its channel list unconditionally: ADC.cpp:51 channels |= px4_arch_adc_temp_sensor_mask(); On STM32H7 that channel is 20 and lives on ADC3, so the sample path redirects it to STM32_ADC3_BASE. With CONFIG_STM32H7_ADC3 unset the peripheral has no clock, EOC never asserts, and every conversion burns the full 50 us timeout inside a critical section before returning UINT32_MAX. At the 100 Hz board_adc rate that floods the console with ERROR [board_adc] sample timeout and makes dmesg unreadable. The H7 ADC driver assumes this: it force-bumps SYSTEM_ADC_COUNT to 2 when a board declares a single non-ADC3 instance, precisely to leave room for the temperature sensor. The flash argument does not hold. CONFIG_STM32H7_ADC3 gates exactly one statement, regval |= RCC_AHB4ENR_ADC3EN in stm32h7x3xx_rcc.c:385, which disappears into existing alignment padding. Measured before and after: h743 1628356 B 88.74% -> 1628356 B 88.74% (0 bytes) h743pro 1769256 B 96.42% -> 1769256 B 96.42% (0 bytes) h743slim 1755808 B 95.68% -> 1755808 B 95.68% (0 bytes) Verified on H743 Pro hardware: the sample timeout count in dmesg goes from 124 to 0, with battery voltage, current and RSSI unaffected on ADC1. H743 and H743 Slim build clean but were not flashed. Assisted-by: Claude:claude-opus-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

The onboard SPI NOR is a Winbond W25Q128, not a Micron N25Q128. a3030e2aed switched h743 and h743pro to NuttX's m25p driver on the premise that the part was Micron; it is not, so the probe has failed ever since and the board has had no usable storage. Read back over SPI3 on H743 Pro hardware: [boot] W25: JEDEC id ef 40 18 ef = Winbond (m25p accepts only 0x20, Micron/STMicro) 40 = W25Q memory type A (m25p knows 0x20, 0xba, 0xbb) 18 = 128 Mbit / 16 MB m25p_initialize() rejects a manufacturer it does not know and returns NULL, so /dev/mtd0 was never registered and littlefs was never mounted. /fs/microsd stayed an ordinary directory on the RAM rootfs, which is why it listed files while df did not show it: blackbox logs were being written to RAM and lost on every reboot. Parameters were unaffected - FLASH_BASED_PARAMS keeps them in MCU flash sector 15. This went unnoticed because board_app_initialize() reports through syslog(), and PX4's console buffer only captures stdout (px4_init.cpp dup2's fd 1 to /dev/console_buf), so none of the [boot] diagnostics ever reach dmesg. Stock upstream w25.c already recognises this part - W25_JEDEC_WINBOND 0xef, W25Q_JEDEC_MEMORY_TYPE_A 0x40, W25_JEDEC_CAPACITY_128MBIT 0x18 - so no NuttX patch is needed, which was a3030e2aed's actual goal. The downstream patch that pin carried had added Micron IDs to w25.c, solving a problem that never existed. M25P_SUBSECTOR_ERASE is dropped with it: it existed only to give m25p the 4 KB granularity w25 provides natively, confirmed by the mounted filesystem reporting 4096-byte blocks. Every other PX4 board with an onboard SPI NOR dataflash uses w25 (diatone/mamba-f405-mk2, hkust/nxt-dual, x-mav/ap-h743v2); none uses m25p. Verified on H743 Pro hardware: /dev/mtd0 present df: 4096-byte blocks, 4096 blocks, mounted on /fs/microsd H743 builds clean but was not flashed. H743 Slim is unaffected - it has a real microSD on SDMMC2 and no onboard dataflash. Assisted-by: Claude:claude-opus-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

…visible These boards ship with two different SPI NOR parts. Both were seen tonight on H743 Pro hardware: ef 40 18 Winbond W25Q128 -> w25 driver 20 ba 18 Micron MT25Q/N25Q128 -> m25p driver Neither driver accepts the other's manufacturer ID, so whichever single driver the board selects, half the units end up with no storage. That is the whole history of this file: the old downstream NuttX patch added Micron IDs to w25, a3030e2aed switched to m25p, and ca66f12 switched back to w25 - each correct for the board on that developer's desk, each breaking the other batch. Probe w25 first and fall back to m25p, and the board works either way. Costs 1888 bytes on H743 Pro (96.42% -> 96.52%). The reason this took so long to find is the second half of the change. board_app_initialize() reported through syslog(), which reaches the serial console but never PX4's console buffer; px4_platform_init() dup2's stdout onto that buffer, and it is what dmesg reads. So every [boot] diagnostic was invisible to anyone working over USB - which is why an entirely unmounted filesystem went unnoticed since a3030e2aed in June. boot_log() now writes to both paths, since neither alone reaches both audiences. The probe also reads the JEDEC ID up front and reports it either way, so a future mismatch says what the part actually answered instead of just "chip not recognised". All-00 or all-ff distinguishes a failed SPI transaction from an unknown chip - that distinction is what identified the Micron part. Verified on two H743 Pro units, one of each flash type, from one binary: ef 40 18: [boot] flash: chip ok (JEDEC ef 40 18), mounted at /fs/microsd 20 ba 18: [boot] flash: chip ok (JEDEC 20 ba 18), mounted at /fs/microsd df: 4096-byte blocks, 4096 blocks, extras.txt read back H743 builds clean but was not flashed. H743 Slim gets only the boot_log change - it has a microSD on SDMMC2 and no onboard dataflash. Assisted-by: Claude:claude-opus-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

TELEM3 is the digital-VTX / MSP DisplayPort port on all three variants (MSP_OSD_CONFIG 103). msp_osd sets that port to 115200 itself: cfsetspeed(&t, B115200); // msp_osd.cpp:275 tcsetattr(_msp_fd, TCSANOW, &t); so the port has always run at 115200 while SER_TEL3_BAUD still reported the 57600 default. Make the parameter agree with the hardware. This is cosmetic for MSP - the driver overrides it either way, which is why the other in-tree boards carrying msp_osd (micoair/h743, h743-aio, h743-v2) set no baud default. It matters when TELEM3 is repurposed: MAVLink honours SER_TEL3_BAUD rather than forcing its own rate, and 57600 is too slow to drive an OSD from MAVLink telemetry. Verified on H743 Pro: SER_TEL3_BAUD reads 115200 from the default with no stored override, and msp_osd runs on /dev/ttyS3 with 0 unsuccessful sends. Assisted-by: Claude:claude-opus-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

The H743 Pro routes the HD VTX connector's pin 3 to PB8 and pin 4 to PB9, reversed with respect to a standard 6-pin DJI/OpenIPC harness where pin 3 carries the flight controller's TX. The STM32H743 offers UART4 TX only on PB9 and RX only on PB8, so this cannot be resolved by selecting different pins -- the peripheral itself has to be swapped. Apply USART_CR2_SWAP once in board_app_initialize() rather than from a driver. CR2.SWAP survives up_setup(), up_set_format() and up_shutdown(), all of which read-modify-write CR2, so a single call at start-up covers every consumer of TELEM3: msp_osd today, mavlink if the port is later reconfigured. ArduPilot drives the same board with the runtime equivalent, SERIALn_OPTIONS bit 3 (SwapTXRX), and Betaflight's target config lists the already-swapped mapping as UART4_TX_PIN PB8. PX4 has no per-port serial options parameter, so board support is the only place this can be applied. Verified on hardware: MSP DisplayPort OSD works on an H743 Pro driving an OpenIPC camera after this change. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

Record that the H743 Pro's HD VTX connector is wired pin 3 to PB8 and pin 4 to PB9, and that PX4 swaps the UART4 peripheral during board start-up so a standard DJI/OpenIPC harness works as labelled, with nothing for the user to configure. Note ArduPilot's runtime equivalent (SERIAL4_OPTIONS bit 3) so readers cross-referencing that documentation do not look for a PX4 parameter that does not exist. The non-Pro places UART4 on PD0/PD1 and is not swapped. The Slim shares the Pro's PB8/PB9 mapping but is likewise not swapped, so its page points at the Pro's behaviour as the thing to check if the OSD does not appear. Also describe what the Dji/VTX solder jumper actually selects: whether the connector's RX4 pin carries UART4 RX or the analog composite video signal. It is not in the OSD's transmit path. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

The Slim shares the H743 Pro's UART4 pin mapping (PB8/PB9) and its HD VTX connector, on which pin 3 -- the pin a standard 6-pin DJI/OpenIPC harness expects to carry the flight controller's TX -- is routed to PB8. Apply the same USART_CR2_SWAP in board_app_initialize() so a stock harness works as labelled. The reversal is confirmed on H743 Pro hardware and assumed here from the shared pin mapping and connector; no Slim was available to test. If a Slim turns out to be wired straight through, dropping BOARD_TEL3_SWAP_RXTX from its board_config.h is the whole change. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

The H743 and H743 Pro have shipped with either a Winbond W25Q128 or a Micron MT25Q/N25Q128, which need different NuttX drivers. The board support probes for both, but nothing told a user that, so a board reporting "chip not recognised" gave no way to tell which part was fitted. Add a Blackbox Storage section to both pages listing the JEDEC IDs and the driver each maps to, and pointing at the boot line that reports the detected ID. The Slim is unaffected: it has a microSD on SDMMC2 and no onboard dataflash. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

Autotune is the normal way to tune a multicopter on PX4, and these are FPV boards whose users will mostly be flying multicopters. Leaving it out meant there was no supported tuning path on them. Every other H7 board of this class enables it: the whole Holybro KakuteH7 family -- the closest analogues to these boards -- along with durandal-v1, pix32v5, all four micoair H743 variants, both x-mav AP-H743s, and every PX4 reference board. The only H7 boards without it are the Matek H743 family, which this board support was originally modelled on, and an F7 Kakute with no flash to spare. There is room: h743 89.02%, h743 Pro 96.84% (from 96.27%), h743 Slim 96.01%. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

…configs These boards shipped fixed-wing and VTOL control without any airspeed support, no way to read a power monitor on a board that has no power module connector, no LED drivers despite an LED pad, and no battery estimate from ESC telemetry. Add what each variant can actually use. The split follows the hardware. The H743 has no CAN, so it needs the directly attached driver families -- barometers, differential pressure and distance sensors -- along with a few utility commands. The Pro and Slim have CAN, and PX4's UAVCAN sensor bridges already publish distance_sensor, sensor_optical_flow, airspeed and differential_pressure without those families being enabled, so they get only what CAN cannot provide. Their configs are identical to each other. SD card benchmarks are left off the H743: it has no SD card slot, only onboard SPI NOR. Flash: h743 96.62%, Pro 98.66%, Slim 97.83%. The Pro is the tight one at 24 KB free -- the remaining candidates (all barometer drivers at 31.7 KB, the full systemcmds set at 48.8 KB, SIH at 40 KB) do not fit alongside UAVCAN and are omitted on that basis. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

The H743 and H743 Pro log to onboard SPI NOR with no SD card, which appears to be unique in the tree: the three other boards with SPI NOR dataflash all have a real SD card as well. NOR must erase before it can write, and littlefs periodically compacts blocks, so the write path stalls for seconds at a time. The tree-wide default 8 KiB logger buffer cannot absorb that, and the logger discards whatever arrives while it is full. Measured on H743 Pro hardware at the default logging profile, ~31 KiB/s over 45 s runs: 64 KiB 65 dropouts, max 1.30 s 128 KiB 36 dropouts, max 3.49 s 256 KiB 27 dropouts, max 1.56 s 451 KiB 5 dropouts, max 4.54 s Larger keeps helping, but a 512 KiB request was clamped to the 451 KiB of free memory -- all of it, leaving nothing for anything else. 256 KiB peaked at 169 KiB used and takes a boot-tested 65 dropouts down to 23. Also cap the log file at 12 MiB. The 1024 MiB default exceeds the 16 MB part, so the cleanup threshold can never be met and the logger reports "14 MiB free, threshold 1025 MiB" and runs its free-space path on every start. The Slim is untouched: it has a real microSD on SDMMC2. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

…device I2C2 carries the onboard SPL06 barometer and is also broken out for an optional external magnetometer. That was expressed by declaring the bus external and overriding px4_i2c_device_external() to report the SPL06 back as internal, so it kept calibration priority. px4_i2c_device_external() no longer exists: buses now carry a BusTopology of Internal, External or Shared, and Shared describes this bus exactly. Use initI2CBusShared(2) and drop the override along with BOARD_OVERRIDE_I2C_DEVICE_EXTERNAL. Start the barometer with -I rather than -X to go with it. A device's external flag follows the bus filter it was found through, so -X would have registered the onboard sensor as external and lost the calibration priority the override existed to protect; a shared bus is claimed as internal when the start line pins -b, which this one already does. The external magnetometer still finds the bus, since a shared bus reports as external too. Fixes the build against current main, where the override's call to px4_i2c_bus_external() no longer resolves. Assisted-by: Claude:claude-fable-5 Signed-off-by: Nir Mor <nir.mor@gmail.com>

mor2code · 2026-08-29T19:23:14Z

Flight log from the DAKEFPV H743 Pro as requested: https://logs.px4.io/plot_app?log=4f38f971-2a74-4382-ac2a-aaebb852aa41

Manual (Stabilized) hover test, ~75 s, on this PR's board support.

The branch is also rebased onto current main (3f6b26f90b), which includes the new bus-topology sensor classification: the onboard SPL06 and the external magnetometer on the shared I2C2 are handled with initI2CBusShared + -I -b 2, the same pattern as 3f6b26f90b for ARK fmu-v6xrt.

mor2code · 2026-08-29T19:43:15Z

@dirksavage88 re-requesting your review — every thread from June is resolved. The two I2C ones are worth a fresh look: with the bus-topology classification now in main (#28352), I2C2 is declared initI2CBusShared(2) and the onboard SPL06 starts with -I -b 2, so the internal/external question is answered by the API rather than a per-device override (same pattern 3f6b26f90b uses for ARK v6xrt). Verified on hardware: baro reports internal, the external mag on the same bus reports external. Rebased on current main, CI green, flight log above.

github-actions Bot added kind:feature Request or change that adds new functionality. scope:dependencies Dependency or submodule updates. scope:build-system CMake, Kconfig, board config, or build tooling. scope:boards Board-specific changes or hardware definitions. scope:docs labels May 30, 2026

mor2code force-pushed the feature/dakefpv branch from cdfa7a4 to ef7eff1 Compare May 30, 2026 01:28

This was referenced May 30, 2026

feat(boards/dakefpv): add DAKEFPV H743 Pro board support #27380

Closed

feat(boards/dakefpv): add DAKEFPV H743 board support #27389

Closed

feat(boards/dakefpv): add DAKEFPV H743 Slim board support #27404

Closed

farhangnaderi requested a review from hamishwillee June 5, 2026 18:57

dirksavage88 self-requested a review June 5, 2026 18:58

farhangnaderi reviewed Jun 6, 2026

View reviewed changes

dirksavage88 requested changes Jun 8, 2026

View reviewed changes

Comment thread boards/dakefpv/h743/nuttx-config/include/board.h Outdated

Comment thread boards/dakefpv/h743/init/rc.board_sensors Outdated

dirksavage88 requested changes Jun 8, 2026

View reviewed changes

Comment thread boards/dakefpv/h743slim/src/spi.cpp

Comment thread boards/dakefpv/h743slim/src/i2c.cpp Outdated

mor2code force-pushed the feature/dakefpv branch from 4ada72c to 3034603 Compare June 10, 2026 02:00

mor2code and others added 27 commits August 29, 2026 21:53

docs(docs): Shrink images

6b5b016

docs(docs): Minor subedit

aa81e07

fix(boards/dakefpv): enable CONFIG_PTHREAD_MUTEX_TYPES

c5af176

mavlink_main.cpp now requires it for its recursive per-channel send mutex and fails the build with an #error otherwise. Other boards (px4/fmu-v6x, matek/h743-mini) already set it. Signed-off-by: Nir Mor <nir.mor@gmail.com>

mor2code force-pushed the feature/dakefpv branch from 24e1cbe to ad307be Compare August 29, 2026 18:58

board	before	after
h743	1628356 B (88.74%)	1628356 B (88.74%)
h743pro	1769256 B (96.42%)	1769256 B (96.42%)
h743slim	1755808 B (95.68%)	1755808 B (95.68%)

Uh oh!

Conversation

mor2code commented May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Highlights

NuttX submodule change (please read)

Testing

Uh oh!

github-actions Bot commented May 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔎 FLASH Analysis

Uh oh!

github-actions Bot commented May 30, 2026

Uh oh!

mor2code commented Jun 5, 2026

Uh oh!

farhangnaderi commented Jun 5, 2026

Uh oh!

farhangnaderi commented Jun 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

farhangnaderi left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mor2code commented Jun 7, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mor2code commented Aug 29, 2026

Uh oh!

mor2code commented Aug 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

mor2code commented May 30, 2026 •

edited

Loading

github-actions Bot commented May 30, 2026 •

edited

Loading

farhangnaderi commented Jun 6, 2026 •

edited

Loading