AP_Periph only instantiates an AP_Airspeed object when
AP_PERIPH_AIRSPEED_ENABLED is set, but AP_AIRSPEED_ENABLED defaulted to
1 regardless, leaving the singleton null on other periph builds. Tie
the two together as is already done for other sensor libraries.
This reverts commit 2f87db990f.
PR #34359 was merged by mistake. On the bench, with an ESC on
YJUAV_A6SE_H743 output 1, the hold presents a continuous high (full
throttle to a PWM ESC) for about 10.5s after every reset, and for as
long as safety is engaged when output 1 is a motor outside
BRD_SAFETY_MASK, which is Copter's default. The ESC started to enter
throttle calibration. Back the change out until the hold can be
chosen per output.
This reverts commit 239f5c1f97.
PR #34359 was merged by mistake. On the bench, with an ESC on
YJUAV_A6SE_H743 output 1, the hold presents a continuous high (full
throttle to a PWM ESC) for about 10.5s after every reset, and for as
long as safety is engaged when output 1 is a motor outside
BRD_SAFETY_MASK, which is Copter's default. The ESC started to enter
throttle calibration. Back the change out until the hold can be
chosen per output.
This reverts commit 67fd60ce26.
PR #34359 was merged by mistake. On the bench, with an ESC on
YJUAV_A6SE_H743 output 1, the hold presents a continuous high (full
throttle to a PWM ESC) for about 10.5s after every reset, and for as
long as safety is engaged when output 1 is a motor outside
BRD_SAFETY_MASK, which is Copter's default. The ESC started to enter
throttle calibration. Back the change out until the hold can be
chosen per output.
PWM1 is on PA15, the JTDI pin, whose reset and power-on pull-up gave the
M1 servo a short pulse on every boot. Declare it HOLD_HIGH so the
application keeps it a pulled-up input until RCOutput's first real
frame, matching the bootloader, which already keeps the pull-up.
The STM32 JTAG pins JTDI (PA15) and NJTRST (PB4) come out of every
reset, and out of power-on, with an internal pull-up enabled, and 84
hwdef directories in the tree route a PWM output through one of them:
61 through PA15, 38 through PB4, 15 through both. A servo on such an
output sees the line pulled high from then until firmware reconfigures
the pin. On the H743 that measured 692us to the bootloader's board init
on a warm reset, and 496us and 520us on two cold power-ons. Each is a
pulse inside the range servos accept, so the servo drives to an endpoint
and holds it through the rest of the boot. Nothing can shorten that
window, since no code runs during it.
Give hwdef a HOLD_HIGH keyword for PWM pins. The generator emits such a
pin as a pulled-up input with its timer alternate function preset, and a
HAL_PWM_HOLD_HIGH_MASK of the channels concerned. It rejects the keyword
on any pin RCOutput will never hand back to a timer: anything other than
a PWM(n) timer output in the main configuration, so also an RC input, the
alarm and an ALT(n) pin. One predicate decides both that and which pins
get a mask bit, so the two cannot disagree. The check is made when the
pin is parsed, which covers bootloader builds too. STM32F1 is rejected
outright, since its pin setup does not honour the keyword at all.
RCOutput keeps each channel an input until the first non-zero value is
pushed to it, in the PWM and DShot output paths, and only then switches
the pin to the timer. With the bootloader also keeping the pull-up, the
line is high continuously from the reset until the first real frame,
which for a channel outside BRD_SAFETY_MASK means until safety is
disarmed, so the servo sees a high far longer than any valid pulse
rather than a plausible short one followed by seconds of silence. On
the bench the test servo did not move at all across ten reboots.
The mode switch is an unlocked read-modify-write of the port registers,
and other threads change the modes of other pins on the same port, so
a single write can be lost. The channel is therefore not marked handed
over until a later output finds the pin already in alternate mode; until
then each output writes the mode again, so a lost write is repaired one
output later rather than leaving the pin an input until reboot.
Several other owners of a pad have to take it explicitly, because none
of them goes through the normal output path:
- the alarm driver configures a timer and never the pad, and disables
the group's channels first, so the hold on the alarm's own channel is
released before that. Only that channel: no real frame will ever
arrive for the rest of the group, so a HOLD_HIGH pin among them is
correctly left held;
- soft serial saves and restores the pad's mode, so BLHeli passthrough
hands the pin over when it selects it, or it would save "input" and
transmit nothing;
- neopixel and ProfiLED output is chosen at runtime by SERVOx_FUNCTION
on an ordinary PWM(n) pin and is sent without push_local(), so the
serial LED path releases its group's pads before driving them;
- DShot commands such as beeps are sent before arming, when nothing has
released the pad yet, so the command path releases every channel it
transmits on;
- bidirectional DShot, when enabled at runtime, takes the pads of a
whole group during init, so it clears the pending bit there. A pin
merely declared BIDIR keeps its hold; one whose group has bidirectional
DShot enabled gets no protection. The hwdef allows HOLD_HIGH and BIDIR
together deliberately.
Verified under Renode on YJUAV_A6SE_H743 with ArduPlane: the
application's board init leaves PA15 an input, it stays one through
24.8s of init, and the mode write that puts it on TIM2 lands at the same
microsecond as the first non-zero CCR1 write. With the first mode write
dropped on purpose, the next output found PA15 still an input and wrote
it; unmodified, the second output sees the mode has held and later
outputs no longer read the port. MatekF405-TE and the IOMCU
firmware still build, and a no-mask board's firmware is byte-identical.
PA15 drives PWM1 on this board and is also JTDI, which the STM32H743
brings out of every reset, and out of power-on, with its internal
pull-up enabled. The M1 servo line is therefore held high from then
until the bootloader's board init reconfigured the pin as a floating
input. On logic-analyser captures of the real board that is 692us on a
warm reset, and 496us and 520us on two cold power-ons, one over USB and
one at 12V. Each of those is a pulse inside the range most servos
accept, and it sent the servo to an extreme.
Configure PA15 as an input with pull-up in the bootloader instead, so
the line stays high continuously until the application switches the pin
to its timer, whose idle level is low. The servo then sees one high
lasting the whole bootloader, far outside any valid pulse width, rather
than a plausible command. Verified under Renode with the bootloader
held: PA15 reads input with pull-up while the bootloader owns the pins.
The CoreWing F405 Wing Mini V2 is a compact variant of the
CoreWingF405WingV2. The hwdef inherits from the base target and only
overrides the Mini-specific hardware differences.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The CoreWing F405 Wing V2 is a fixed-wing and QuadPlane/VTOL flight
controller with an STM32F405 MCU, ICM-42688P or BMI270 IMU, SPA06-003
baro, AT7456E OSD, integrated PDB and a USB extender connector for an
optional BLE/WiFi telemetry module.
Co-authored-by: Henry Wurzburg <hwurzburg@yahoo.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hardware revision 1 replaces the IIM-42653 with an LSM6DSV32X on the
same SPI1 CS and DRDY pins. Probe both devices so a single firmware
image supports both revisions.
Each of these "define NAME value" lines creates a macro which no code,
script or ChibiOS source references, so they have no effect:
- ALLOW_ARM_NO_GPS (AeroCogito-H7Digital): no such macro (unlike
ALLOW_ARM_NO_COMPASS, which is consumed by AP_Arming_Copter.cpp)
- AP_BATTERY_TIBQ76952_I2C_DEVICE (VM-L431-BMS): driver uses
AP_BATTMON_TIBQ76952_BUS/_ADDR
- AP_COMPASS_IST8308_DEFAULT_ROTATION (GreenSightUltraBlue): no such
macro; rotation comes from the COMPASS line
- HAL_BLHELI_PASSTHROUGH_ENABLED/_UART and
HAL_ESC_TELEMETRY_UART/_ENABLED (NucleoH753ZI): no such macros
- HAL_CAN_ENABLED, HAL_CAN_NUM_DRIVERS (SkyRukh_Surge_H7): obsolete;
CAN interface count is derived from the CAN pin definitions
- HAL_HEATER3_GPIO_PIN, HAL_HEATER4_GPIO_PIN (rFCU): IMU_heater.cpp
only supports HAL_HEATER_GPIO_PIN and HAL_HEATER2_GPIO_PIN
- HAL_BL_IOMCU_FW_DETECT and HAL_IO_FMU_COMMS_TX_DMA_CHANNEL/
_RX_DMA_STREAM/_RX_DMA_CHANNEL (CubeRedSecondary-IO): iofirmware
only consumes HAL_IO_FMU_COMMS_TX_DMA_STREAM and
HAL_IO_FMU_COMMS_TX_IRQ_PRIORITY, which are retained
- HAL_LED_OFF (OrqaH7QuadCore, SkystarsH7HD bootloaders): bootloader
uses HAL_LED_ON and derives off as !HAL_LED_ON
- HAL_BOOTLOADER_NAME, HAL_BOOTLOADER_BOOT_FROM_SDCARD
(PilotGaeaSH7V1-bdshot): no such macros; SD-card boot would be
AP_BOOTLOADER_FLASH_FROM_SD_ENABLED
- HAL_BUZZER_ON (SIMPLIFLYH7): no buzzer-polarity macro exists
- HAL_NEOPIXEL_COUNT (KakuteF4): no such macro; LED count comes from
the NTF_LED_LEN parameter
- VDD_BRICK2_VALID (sparknavi-blue): only meaningful as a pin label,
which this board does not have; as a bare define it does nothing
- HAL_HEATER_MAG_OFFSET_RM3100 (ZeroOneX6): the consuming
HAL_HEATER_MAG_OFFSET define is commented out, and the offset
vector is zero in any case
All affected boards still process cleanly through chibios_hwdef.py.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Some STM32F4 CMSIS headers omit the unsupported SDIO start-bit error flag. Define it as zero when absent, matching the ChibiOS SDIO driver and allowing DrotekP3Pro builds to compile.
RCOutput_iofirmware.cpp carried a second copy of the decode table, used by
the reversed-channel decoder on STM32F1. That copy is live: PB8 and PA1 are
declared BIDIR on iomcu-f103-dshot, so those channels kept the old
one-in-sixteen false accept rate while the main path was fixed.
Hoist the table, the quintet check and the checksum into one helper so the
two cannot drift again. Removing the duplicate saves 172 bytes on the F103,
which has 8k of flash left.
The GCR decode table used 0 for the sixteen quintets the encoding never emits,
which is indistinguishable from the legitimate 0 at index 25. A corrupt quintet
therefore decoded silently to nibble 0, leaving only the checksum between it and
a bad eRPM - and four bits of checksum let roughly one in sixteen corruptions
through.
Mark the impossible quintets and reject any word containing one. Betaflight
reports 5-8% of frames failing to decode with motors running, so this path is
exercised constantly, and a bad eRPM feeds RPM-referenced harmonic notch
tracking.
Add an early boot service that exports the microSD block device over
USB mass storage before the filesystem and normal flight application
start. The service retains exclusive ownership until a power cycle and
continues servicing the watchdog.
Enable the service on supported boards, provide explicit build control,
increase the MSD worker stacks for the SD wait path, scope the ChibiOS
fixed-width serial warning suppression to the MSD object, and reject
explicit enable requests on unsupported boards.
The shared module inc probed the ICM-45686 at 24MHz, the part's rated
maximum. Every other icm45686 in the tree probes at 2MHz and only steps
up afterwards. The high-speed clock is unchanged at 24MHz.
Pull module-fixed pins (MCU type, oscillator, CAN1, USB, SWD, RMII
Ethernet PHY, on-module SPI3 IMU pads, CAN sleep/shutdown) into
hwdef.inc and hwdef-bl.inc so additional carrier boards built on the
CubeNode H757 module can reuse them without duplicating the module
pinout. The existing CubeNode AP_Periph dat files become thin wrappers
over the shared inc plus their AP_Periph-specific config.
CubeNode-ETH continues to include CubeNode/hwdef.dat unchanged.
The VTX power switch pin is defined with a default OUTPUT level in
hwdef.dat, but was never mirrored into hwdef-bl.dat. Since ChibiOS's own
unconfigured-pin default is INPUT FLOATING, the pin floated for the
entire time each of these boards sat in the bootloader (DFU / SD-card
flashing), even though the main firmware correctly drove it once it
booted. Add the matching line so the VTX power rail has a defined state
throughout.
- AEDROXH7 (PB12 VTX_SW)
- DAKEFPVF405 (PB4 VTX_PWR)
- DAKEFPVH743Pro (PE3 PINIO2)
- FlyFishRCF405 (PC5 PINIO1)
- HWH7 (PE4 VTX_POWER)
- JHEMCUF405WING (PC13 PINIO1)
- LongBowF405WING (PC13 PINIO1)
- OrqaF405Pro (PB9 VTX_SW)
- SIMPLIFLYH7 (PB2 PINIO1)
- SPEDIXH743 (PA2 VTX_SW)
- SpeedyBeeF405WING (PC13 PINIO1)
- speedybeef4v5 (PC13 VTX_PWR)
STM32F405 based board with ICM-42688-P IMU, DPS310 barometer,
MAX7456 OSD, onboard dataflash, 8 PWM outputs, hardware SBUS
inverter on USART2, and USB OTG.
Processing these hwdefs printed "<name> already in defines with same
value". In four of them the board repeats a define it has just taken
from the hwdef it includes:
DAKEFPVH743 DEFAULT_NTF_LED_TYPES from DAKEFPVH743Pro
MatekF765-Wing-bdshot DEFAULT_NTF_LED_TYPES from MatekF765-Wing
SkystarsH7HDv2 AP_MSP_VIDEOTX_ENABLED from SkystarsH7HD-bdshot
TBS_LUCID_H7_WING DEFAULT_NTF_LED_TYPES from TBS_LUCID_H7
and in the other two the same define appears twice in the one file:
sparknavi-blue HAL_WITH_RAMTRON
esp32diy HAL_LOGGING_BACKENDS_DEFAULT
The generated hwdef.h held each of these twice, as an identical
redefinition, and now holds it once; the value reaching the compiler is
unchanged. hw.dat loses the line too, so it and the ROMFS which
embeds it are one line shorter.
Parsed state - defines, intdefines, config, pins and the rest - is
unchanged for all 490 boards.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three places looped over af_labels asking whether a label named an
alternative function, and none of them used the entry which matched.
str.startswith() takes a tuple of prefixes and does the whole test at
once, so ask it that way instead; two of the three are in
get_alt_function(), which is called for every pin line.
Processing all 443 ChibiOS hwdefs goes from 0.335s to 0.325s. The
parse state of all 490 boards is unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
valid_type() still ran nine uncompiled re.match() calls for every pin
line, cross-checking the peripheral number in a pin's type against the
one in its label. Compile them once as class members.
Processing all 443 ChibiOS hwdefs goes from 0.35s to 0.32s. The parse
state of all 490 boards is unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Peter Barker
yyzh
Andy Piper
Brown
zhoujinhuaandClaude Opus 5
rubikscube05
gradvizor
alexklimaj
tompsontan
Andrew Tridgell
msli-dev
abhijithcv
Jacob Dahl
HGLRC
RomanKalinchuk
serkanMzlm
dakefpv