Repository navigation
Conversation
PLL1 VCI input is HSE/M = 2 MHz on all H7 targets, which falls in the 2-4 MHz range (VCIRANGE_1). The previous VCIRANGE_2 (4-8 MHz) was incorrect and affected PLL charge pump calibration. Fixes #11602
Remove redundant prose that duplicated the assert, remove board-specific name from shared init code, and shorten the assert slug to match codebase conventions.
…cceleration function
The ICM42688 gyro on IMU1 was registered with DEVHW_MPU6000 instead of DEVHW_ICM42605, preventing the ICM42605 driver from detecting it. Boards populated with ICM42688 chips would fail to detect the primary gyro. The IMU2 registration was already correct. Affected targets: GEPRC_TAKER_H743, GEPRCF745_BT_HD Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* timeUnixUsec is declared as timeUs_t ... * The new SoftRF section says SYS_STATUS, VFR_HUD, and ATTITUDE are “not supported”, .... * Spelling/casing: the receiver name is “SoftRF” ... * Spelling/casing: use “MAVLink” ... * Formatting deviates from the prevailing style i ... * The comment on the EXTRA2 stream rate still says “HEARTBEATs are important” ...
* fix mavlink data stream, create new schedule for HB and sys time
* Add new target: AEDROXH7 (Airbot Systems AEDROX H7) STM32H743 flight controller with ICM42688P gyro, W25N01G NAND flash, DPS310 baro, MAX7456 analog OSD, HD OSD via MSP DisplayPort, and 8 motor outputs split across TIM1 and TIM8. SPI3 MOSI on PB2 requires explicit GPIO_AF7_SPI3 override. Magnetometer enabled on I2C1 (hardware present, not in BF config). * AEDROXH7: replace UART4 with DroneCAN on PD0/PD1 PD0/PD1 connect to the CAN transceiver (CANL/CANH pads visible on board), not to a user-accessible UART4 header. Replace UART4 with USE_DRONECAN defines. CAN standby pin TBD pending INAV syntax confirmation. * AEDROXH7: add CAN1_STANDBY PD3 (not yet tested) * CI: re-trigger build to pick up fc_msp.c sign-compare fix in maintenance-9.x
…top functions STM32 RM (RM0090 §10.3.17) requires disabling the timer DMA request before disabling the DMA stream. The previous code had this backwards in five places across three driver files, creating a race window where the timer could issue a DMA request to an already-disabled stream. The incorrect ordering: DMA_Cmd(stream, DISABLE); // stream disabled first TIM_DMACmd(tim, source, DISABLE); // timer request disabled second Corrected ordering: TIM_DMACmd(tim, source, DISABLE); // timer request disabled first DMA_Cmd(stream, DISABLE); // stream disabled second Affected locations: - timer_impl_stdperiph.c: impl_timerPWMStopDMA, impl_timerPWMPrepareDMA, DMA TC IRQ handler - timer_impl_stdperiph_at32.c: impl_timerPWMStopDMA - timer_impl_hal.c: DMA TC IRQ handler The correct ordering was already used in impl_timerPWMSetDMACircular (both stdperiph files) and impl_timerPWMStopDMA (HAL file), which serve as the reference implementation.
Removed redundant phrases and clarified manufacturer information.
# Conflicts: # src/main/io/osd.c
[FIX] Prevent stack smashing via unbounded OSD message array writes
Fix the Parameter Group Version Check so it can run on pull requests (backport to release/9.1)
Reserves the next firmware patch number on release/9.1 ahead of setting the 10.0 version string on maintenance-10.x, per the major-version patch-reservation procedure.
Bump version to 9.1.1
Release/9.1 to master
maintenance-9.x -> maintenance-10.x (now the compatible/current choice) maintenance-10.x -> maintenance-11.x (now the breaking/next-major choice) maintenance-11.x was just created off maintenance-10.x's tip, per the release process's "create the next major's branch at first RC" rule.
Merging to master means the change never ends up in any release, rather than implying that's an acceptable default.
…ion-release91 Update PR branch-suggestion workflow for maintenance-11.x
…ion-release91 docs: update pr-branch-suggestion README entry for 10.x/11.x cycle
The legacy LSM6DXX config path enabled the gyro's on-chip HPF at its slowest (16mHz) cutoff. That filter has a ~10s RC time constant, so its output keeps settling for ~20-30s after every power-on - well past INAV's ~2s startup gyro calibration window. The result is a real step in the raw gyro reading after calibration has already locked in a zero, which the AHRS reads as several seconds of attitude drift after boot. INAV already zeroes gyro bias in software, making the on-chip HPF redundant, and no other accgyro driver in the tree enables one.
Disable LSM6DSL/DSO/DS3 on-chip gyro high-pass filter
gpsProcessNewDriverData() copies gpsSolDRV over gpsSol including flags.gpsHeartbeat, which is only ever toggled on gpsSol afterwards. With UBLOX and HITL the copy and the toggle run back-to-back, so the flag has been a constant since 8.0.0 and the IMU, which waits for a change, never refreshed its GPS-based inertial compensation: VELNED was dead on all platforms, and the fixed-wing TURNRATE GPS speed froze once it was gated on the same flag in 9.1.0. Unit test links the real gps.c and checks that the flag toggles once per solution and survives a driver copy on its own. Fixes #12029 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit 2d5fd06)
Since the GPS speed is only recomputed on a new GPS solution, the PT1 filter was also only applied then, but with the IMU loop dT. That stretched its 53 ms time constant to seconds and turned the longitudinal term into one spike per GPS frame. Only the square root stays gated. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit ec06947)
GPS heartbeat stuck: AHRS inertial compensation never updated (VELNED since 8.0, FW TURNRATE since 9.1)
…ing-wasm-pwa docs: document configurator macOS signing and WASM SITL/PWA release flow
Remove Duplicate OSD HD Rx Stats Line
…ow-path Only consume artifacts from the real firmware workflow
…around validate-pg-for-release.sh compared against cmake/pg_struct_sizes.reference.db as it stood in the working tree, which is rewritten during development, so a struct whose version was bumped earlier in the cycle could hide a later size change. It also flagged a valid 15 -> 0 version increment, since PG versions are 4 bits. - Baseline is now the reference database committed at the newest final release tag reachable from HEAD (--baseline-tag overrides) - A version change is any difference modulo 16 - Structs whose PG version cannot be determined are skipped, not recorded - Exit 2 when no baseline or no current sizes are available
The next release validates against cmake/pg_struct_sizes.reference.db as committed at the release tag, but the validator only rewrote the working copy and the documented tag step does not commit it, leaving later releases with a stale baseline. - Exit 3 when the validated sizes differ from the database at HEAD, after writing the new database, with instructions to commit it before the freeze - Report when the database is already up to date - Release procedure: run validation before the freeze and commit the database
…ound-tag Fix PG release validation: compare against last release tag, handle 4-bit wraparound
Release/9.1 into master
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )