AP_HAL_ChibiOS: Add HGLRC_H743_PRO board support

[HGLRC-T]

Summary

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

Adds support for the HGLRC H743 PRO flight controller.

The board uses an STM32H743VI, ICM42688-P IMU, SPA06-003 barometer,
AT7456E analog OSD, 16 MiB SPI flash, eight motor outputs, a serial LED
output, switchable 10 V VTX power, and a dual-camera analog switch.

The battery voltage divider is 20K:1K, so the default voltage multiplier
is set to 21.0.

Hardware verification

• USB connection and MAVLink communication verified
• ICM42688-P detected and IMU orientation verified
• SPA06-003 barometer detected and pressure/altitude readings verified
• UART2 serial RC input verified with CRSF/ELRS
• UART4 SBUS input verified
• All eight motor outputs verified
• Addressable LED output verified
• AT7456E analog OSD verified
• VTX 10 V relay verified
• Camera-switch relay verified
• Battery voltage measurement verified with a bench supply
  • Supply voltage: <value> V
  • Reported voltage: <value> V
• Battery current measurement verified with a known load
  • Load current: <value> A
  • Reported current: <value> A
• I2C connector and external pull-ups verified

[andyp1per]

Automated hwdef review (/hwdef-check)

PR 33873 · base upstream/master · new board HGLRC_H743_PRO

Build

• ./waf configure --board HGLRC_H743_PRO: pass
• ./waf copter: pass (1407740 B used, 296184 B free)
• Required files present; board ID 1526 is unique.

Must-fix

Everything is in one commit. ArduPilot wants one commit per subsystem: AP_Bootloader: for board_types.txt, bootloaders: for the _bl.bin/_bl.hex pair, AP_HAL_ChibiOS: for the hwdef directory.

hwdef.dat:107 - HAL_BATT_VOLT_SCALE 200 is off by roughly an order of magnitude. It's the only value >= 100 anywhere in the tree; the rest sit between 10 and 21, and 12S boards use ~21. At 12S a 200:1 divider puts 0.25 V into a 3.3 V ADC, which would throw away most of the range. HAL_BATT_CURR_SCALE 120 is also high (100 is the in-tree maximum, used by 7 boards) though not impossible. Please measure both against a bench supply and a known load.

The PR description is the unfilled template - no summary, no description, no testing checkboxes ticked. For a new board that's the only evidence a reviewer has. Please say what was verified on hardware: IMU orientation, baro, USB, RC input, all 8 motor outputs, the VTX and camera relays, and the battery readings above.

Should-fix

hwdef.dat:28 - SERIAL_ORDER skips USART6 without a placeholder, so SERIAL6 is UART7 and SERIAL7 is UART8. README:30 tells users the pads are marked Rn/Tn for UARTn, so anyone wiring to T7 will reach for SERIAL7 and land on UART8. Every comparable board inserts EMPTY to keep the numbering aligned (BROTHERHOBBYH743/hwdef.dat:90, AEDROXH7/hwdef.dat:30, BeastF7v2/hwdef.dat:26); this is the only board in tree with the un-placeheld form. Suggest SERIAL_ORDER OTG1 USART1 USART2 USART3 UART4 UART5 EMPTY UART7 UART8, with defaults.parm and the README table renumbered to follow.

Related: README:13 claims 8 UARTs but the hwdef defines 7. If USART6 really is broken out on the board, it's missing from the hwdef; if not, the count needs correcting.

The addressable LED doesn't work out of the box. README:15 and :62 advertise it and hwdef.dat:84 assigns PWM(9), but nothing sets SERVO9_FUNCTION 120 and the NeoPixel notify type is never enabled. AEDROXH7 is the direct analogue - SERVO9_FUNCTION 120 in defaults.parm plus define DEFAULT_NTF_LED_TYPES 455 in hwdef.dat.

README:38 lists SERIAL4's default use as "RC input (SBUS)", but nothing sets SERIAL4's protocol, so the in-code default applies and it comes up as GPS. Either set the protocol or fix the column.

defaults.parm holds settings that belong in hwdef.dat (§7.6). OSD_TYPE 1 is a straight duplicate - hwdef.dat:152 already sets HAL_OSD_TYPE_DEFAULT 1. SERIAL5_PROTOCOL -1 is a no-op since SERIAL5+ already defaults to None. The remaining SERIALn_PROTOCOL lines want define DEFAULT_SERIALn_PROTOCOL in hwdef, and the relay block has an established hwdef form (RELAY1_PIN_DEFAULT, as in BlitzH743Pro/hwdef.dat:118 and BROTHERHOBBYH743/hwdef.dat:161). To be fair, ~50 boards do put serial protocols and OSD_TYPE in defaults.parm, so that part isn't unprecedented - but the duplicated OSD_TYPE should go regardless.

Dead or redundant defines:

• hwdef.dat:98,99 HAL_BUZZER_ON / HAL_BUZZER_OFF - neither name is read anywhere in the tree
• hwdef.dat:112 AP_BARO_SPL06_ENABLED 1 - the BARO SPL06 line already emits it (generated hwdef.h:243)
• hwdef.dat:165 HAL_COMPASS_AUTO_ROT_DEFAULT 2 - already the default (AP_Compass.cpp:72)
• hwdef.dat:141 HAL_DEFAULT_INS_FAST_SAMPLE 3 - single IMU here (INS_MAX_INSTANCES 1), so bit 1 is a no-op; use 1

hwdef.dat:89 - LED3 on PD7 gets GPIO(2) but only AP_NOTIFY_GPIO_LED_2_ENABLED is set and HAL_GPIO_C_LED_PIN is never defined, so the pin just sits at its idle level. Either add define AP_NOTIFY_GPIO_LED_3_ENABLED 1 with define HAL_GPIO_C_LED_PIN 2, or drop the line.

Notes

STM32_ST_USE_TIMER 12 with CH_CFG_ST_RESOLUTION 16 is valid, and the override is genuinely needed because TIM5 drives the LED strip. But TIM2 is unused on this board and is 32-bit, so STM32_ST_USE_TIMER 2 would avoid 16-bit tick mode entirely - that's what §7.2 recommends for exactly this case.

Ignore the helper's bootloader STM32_ST_USE_TIMER mismatch warning. The bootloader has no PWM, and virtually no board in tree sets it in hwdef-bl.dat.

BARO SPL06 is correct for the SPA06-003 despite the name - the driver detects chip ID 0x11 as SPA06 (AP_Baro_SPL06.cpp:131). Flagging so nobody "fixes" it.

BIDIR placement is right: one per channel pair (CH1 and CH3 on both TIM1 and TIM4) and nothing on TIM4_CH4. DMA_NOSHARE/DMA_PRIORITY on TIM1_UP/TIM4_UP/SPI1 is the correct call.

DMA2 stream 7 carries six peripherals: USART1_TX (the MSP DisplayPort VTX link), UART7_TX, UART8_TX, TIM5_UP (LED strip), SPI2_RX (OSD) and SPI3_RX (dataflash). Everything did get a stream and sharing is normal on H7, but that's a crowded stream for a link §13.1 calls high-priority - worth checking DisplayPort behaviour with logging active.

Clock is 400 MHz (HAL_EXPECTED_SYSCLOCK 400000000) since MCU_CLOCKRATE_MHZ isn't set; 26 H743 boards set 480. Deliberate?

I2C1 pull-ups: PB7/PB8 are bare, which is correct if the board fits external resistors and non-functional if it doesn't - the .dat can't distinguish the two. Please confirm. The SPA06 is the only device on the bus, so a missing pull-up shows up as a missing baro.

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

[HGLRC-T]

Automated hwdef review (/hwdef-check)

PR 33873 · base upstream/master · new board HGLRC_H743_PRO

Build

• ./waf configure --board HGLRC_H743_PRO: pass
• ./waf copter: pass (1407740 B used, 296184 B free)
• Required files present; board ID 1526 is unique.

Must-fix

Everything is in one commit. ArduPilot wants one commit per subsystem: AP_Bootloader: for board_types.txt, bootloaders: for the _bl.bin/_bl.hex pair, AP_HAL_ChibiOS: for the hwdef directory.

hwdef.dat:107 - HAL_BATT_VOLT_SCALE 200 is off by roughly an order of magnitude. It's the only value >= 100 anywhere in the tree; the rest sit between 10 and 21, and 12S boards use ~21. At 12S a 200:1 divider puts 0.25 V into a 3.3 V ADC, which would throw away most of the range. HAL_BATT_CURR_SCALE 120 is also high (100 is the in-tree maximum, used by 7 boards) though not impossible. Please measure both against a bench supply and a known load.

The PR description is the unfilled template - no summary, no description, no testing checkboxes ticked. For a new board that's the only evidence a reviewer has. Please say what was verified on hardware: IMU orientation, baro, USB, RC input, all 8 motor outputs, the VTX and camera relays, and the battery readings above.

Should-fix

hwdef.dat:28 - SERIAL_ORDER skips USART6 without a placeholder, so SERIAL6 is UART7 and SERIAL7 is UART8. README:30 tells users the pads are marked Rn/Tn for UARTn, so anyone wiring to T7 will reach for SERIAL7 and land on UART8. Every comparable board inserts EMPTY to keep the numbering aligned (BROTHERHOBBYH743/hwdef.dat:90, AEDROXH7/hwdef.dat:30, BeastF7v2/hwdef.dat:26); this is the only board in tree with the un-placeheld form. Suggest SERIAL_ORDER OTG1 USART1 USART2 USART3 UART4 UART5 EMPTY UART7 UART8, with defaults.parm and the README table renumbered to follow.

Related: README:13 claims 8 UARTs but the hwdef defines 7. If USART6 really is broken out on the board, it's missing from the hwdef; if not, the count needs correcting.

The addressable LED doesn't work out of the box. README:15 and :62 advertise it and hwdef.dat:84 assigns PWM(9), but nothing sets SERVO9_FUNCTION 120 and the NeoPixel notify type is never enabled. AEDROXH7 is the direct analogue - SERVO9_FUNCTION 120 in defaults.parm plus define DEFAULT_NTF_LED_TYPES 455 in hwdef.dat.

README:38 lists SERIAL4's default use as "RC input (SBUS)", but nothing sets SERIAL4's protocol, so the in-code default applies and it comes up as GPS. Either set the protocol or fix the column.

defaults.parm holds settings that belong in hwdef.dat (§7.6). OSD_TYPE 1 is a straight duplicate - hwdef.dat:152 already sets HAL_OSD_TYPE_DEFAULT 1. SERIAL5_PROTOCOL -1 is a no-op since SERIAL5+ already defaults to None. The remaining SERIALn_PROTOCOL lines want define DEFAULT_SERIALn_PROTOCOL in hwdef, and the relay block has an established hwdef form (RELAY1_PIN_DEFAULT, as in BlitzH743Pro/hwdef.dat:118 and BROTHERHOBBYH743/hwdef.dat:161). To be fair, ~50 boards do put serial protocols and OSD_TYPE in defaults.parm, so that part isn't unprecedented - but the duplicated OSD_TYPE should go regardless.

Dead or redundant defines:

• hwdef.dat:98,99 HAL_BUZZER_ON / HAL_BUZZER_OFF - neither name is read anywhere in the tree
• hwdef.dat:112 AP_BARO_SPL06_ENABLED 1 - the BARO SPL06 line already emits it (generated hwdef.h:243)
• hwdef.dat:165 HAL_COMPASS_AUTO_ROT_DEFAULT 2 - already the default (AP_Compass.cpp:72)
• hwdef.dat:141 HAL_DEFAULT_INS_FAST_SAMPLE 3 - single IMU here (INS_MAX_INSTANCES 1), so bit 1 is a no-op; use 1

hwdef.dat:89 - LED3 on PD7 gets GPIO(2) but only AP_NOTIFY_GPIO_LED_2_ENABLED is set and HAL_GPIO_C_LED_PIN is never defined, so the pin just sits at its idle level. Either add define AP_NOTIFY_GPIO_LED_3_ENABLED 1 with define HAL_GPIO_C_LED_PIN 2, or drop the line.

Notes

STM32_ST_USE_TIMER 12 with CH_CFG_ST_RESOLUTION 16 is valid, and the override is genuinely needed because TIM5 drives the LED strip. But TIM2 is unused on this board and is 32-bit, so STM32_ST_USE_TIMER 2 would avoid 16-bit tick mode entirely - that's what §7.2 recommends for exactly this case.

Ignore the helper's bootloader STM32_ST_USE_TIMER mismatch warning. The bootloader has no PWM, and virtually no board in tree sets it in hwdef-bl.dat.

BARO SPL06 is correct for the SPA06-003 despite the name - the driver detects chip ID 0x11 as SPA06 (AP_Baro_SPL06.cpp:131). Flagging so nobody "fixes" it.

BIDIR placement is right: one per channel pair (CH1 and CH3 on both TIM1 and TIM4) and nothing on TIM4_CH4. DMA_NOSHARE/DMA_PRIORITY on TIM1_UP/TIM4_UP/SPI1 is the correct call.

DMA2 stream 7 carries six peripherals: USART1_TX (the MSP DisplayPort VTX link), UART7_TX, UART8_TX, TIM5_UP (LED strip), SPI2_RX (OSD) and SPI3_RX (dataflash). Everything did get a stream and sharing is normal on H7, but that's a crowded stream for a link §13.1 calls high-priority - worth checking DisplayPort behaviour with logging active.

Clock is 400 MHz (HAL_EXPECTED_SYSCLOCK 400000000) since MCU_CLOCKRATE_MHZ isn't set; 26 H743 boards set 480. Deliberate?

I2C1 pull-ups: PB7/PB8 are bare, which is correct if the board fits external resistors and non-functional if it doesn't - the .dat can't distinguish the two. Please confirm. The SPA06 is the only device on the bus, so a missing pull-up shows up as a missing baro.

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

Fixed all, please review the code again.

[HGLRC-T]

How can we move forward with merging this PR? I see that all CI processes have passed.