飞控芯片实用反馈：2026.6.x 陀螺数据冻结、第二颗陀螺失效与国产 MCU 固件进展

• 证据层级：一级是报告人自己的复现步骤和日志；二级是维护者或厂商版主给出的结论；三级是单方描述、没有可核对的材料。
• 责任分层：同一条现象要判它落在芯片、板级设计、驱动还是配置上，四层分开写。
• 新增的判定：本频道此前没有收录过的一手材料才算新增，按首次报告时间排列；上期收录过的条目一律进历史跟踪，不重复计新增。每期最多 5 条新增，没有就直说「无新增」。
• 正负两面都收。帖子数量不用来推故障率，也不用来看份额；封装和引脚相似，同样不足以证明电气、朝向、软件或系统兼容。

历史条目跟踪

• 待核实点：RGT7 是否会单开 target，还是会按硬件版本拆成两份 config；报告人先前贴错的一组引脚是复制自 VMT7 版本，两个版本的分界还需要板厂或第三方的独立确认。
• 原始链接：betaflight/config Issue #1197

• 待核实点：2026.12 的构建出来之后，AT32F435G／M 上 SPI 挂 SX1280 的实际表现；NewBeeDrone LIONBEE V1 的官方 config 有没有跟着上线。
• 原始链接：betaflight/betaflight Pull Request #15797、betaflight/betaflight Issue #15794

本期新增

• 板卡与固件：AxisFlying F7 Pro（STM32F722，ICM42688P 挂 SPI1）；T-Motor Velox F7 SE（target TMOTORVELOXF7SE）；Diatone Mamba MK4 F722 APP（MAMBAF722_2022B，ICM42688P 加 DPS310）；第四块是 Diatone MAMBAF722_2022A，板上陀螺是 MPU6000。四条报告里的固件分别是 2026.6.2、2026.6.2、2026.6.1 和 2026.6.2，都是从 4.5.x 或 2025.12.x 升上来之后出现的。56
• 工况：8 kHz 陀螺、8 kHz PID（pid_process_denom = 1）、双向下传 DShot600、开 RPM 滤波、GPS M10、CRSF 接收机，四块板基本一致；故障都发生在正常飞行中，没有碰撞、电池健康、没有失控保护触发。
• 证据层级：一级。黑盒日志里能看到未滤波陀螺、滤波后陀螺和加速度计在同一秒内先后停住、数值一直到日志结束都不再变化，同时飞控没有重启、接收机链路仍然有效、黑盒继续记录、电机输出继续变化。5另一台的 OSD 数值在坠机前约 0.25 秒冻在屏上，黑盒在 138.218 秒突然中断、没有正常收尾，事后 5 V 仍在（一个靠 5 V 消失才鸣叫的寻机器全程没响，图传还继续供电了 5 分钟以上）。6
• 责任分层：现有材料把责任落在固件与驱动这一层，芯片没有被指向。同一现象横跨四块 STM32F722 板，其中一块用的是 MPU6000 而不是 ICM42688P；另有一台同样 ICM42688P 加 F722 的机架在同一个固件上飞了 6 个电池没有出现。6需要修的是两件事：SPI／DMA 通信出问题之后固件没有把它判成失效，PID 继续拿最后一帧旧数据算输出，越修越偏。
• 复现与解决状态：其中三条仍开放（10 月 8 日提出的两条加这条线上的早期报告），另一条 #15781 在 2026-10-02 关闭为已解决：报告人把 PID loop 降到 4 kHz、电调协议降到 DShot300 之后，连续几个起落完全正常。7维护者给出的解释是 F722 在 8K 下有已知的锁死问题，并且说代码层面的修复会在下一个版本里；报告人自己注意到 2025.12 与 2026.6 的空闲 CPU 占用都在 60% 上下，出问题的是后者，怀疑自己本来就贴着上限。台架上有人用 USB 供电跑约 17 分钟后复现过一次传感器冻结，其余台架复现没有成功。
• 待核实点：8 kHz PID 加双向下传 DShot600 是不是必要条件，还是只是把余量吃光的放大器；2026.6.2 相对 4.5.x 在 IMU 采样与 DMA 调度上多了什么；下一个版本里维护者说的代码修复具体改了哪一段。
• 不能拿来泛化：这是四块板的报告，能说明的是这几个 target 在这套设置下出过问题，既不用来推 STM32F722 或 ICM42688P 的故障率，也不用来看份额。
• 原始链接：betaflight/betaflight Issue #15815（2026-10-08）、Issue #15816（2026-10-08）、Issue #15781（2026-09-30 开帖，2026-10-02 关闭）

• 板卡与版本：Matek H743（MATEKH743，STM32H743），板上两颗 ICM42688P 加 DPS310 气压计，报告人的板子是 H743-V3 那种双 ICM42688P 的排布；固件 Betaflight 4.5.5，统一 target 配置版本 92c695a，台架测试，没有接接收机和图传。8
• 证据层级：一级。同一块板上把 SPI 总线和片选引脚四种组合各刷一次：SPI1 加 PC15 能检测到（证明这颗芯片本身是好的），SPI4 加 PC13 检测不到，SPI1 加 PC13 检测不到，SPI4 加 PE11 检测到并且陀螺速率 8403；后两组只差一个片选引脚。报告人还对上 ArduPilot 4.6.3 的板级硬件定义：PE11 是第二颗 IMU 的片选，PC13 是第三颗 IMU 的片选，而那颗在 H743 上没焊。
• 责任分层：主要落在板级配置——target 头文件把第二颗陀螺的片选写错了。驱动层另有三处会把一次失败放大成永久失败：gyrosDetected 只在它为 0 时才写回，首启存成 0x01 之后就永远跳过第二个槽位，而它又不能通过 CLI 清掉；两颗陀螺硬件 id 不同时，gyro_to_use = BOTH 会被静默改成 GYRO_1 并写进 EEPROM；INT 引脚在初始化时读高就永久放弃注册 EXTI，而这块板正好定义了那个「先读一次、读高就返回」的宏。报告人写 2026.6.2 已经改了前两处。
• 复现与解决状态：2026-10-06 提出，到本期仍开放，修复没有合并。维护者指出 MATEKH743 有多个硬件版本（V1.5 是 MPU6000 加 ICM42605），并请板厂澄清 V4 与早期版本的不兼容；另一位维护者问报告人手上这块板的硬件版本号，报告人还没有答。板厂到本期没有出面回应。
• 待核实点：这块板的硬件版本号，以及 ArduPilot 那张引脚表在 H743 各版本之间是不是一直没变；官方 config 是按版本拆成两份，还是把这行统一改成 PE11；报告人提出的 gyro_init 三处改动会不会进后续版本。
• 原始链接：betaflight/betaflight Issue #15807（2026-10-06）

• 板卡与固件：IFLIGHT_BLITZ_ATF435（AT32F435，板载 IMU 是 ICM42605），刷官方 inav_10.0.0-rc1_IFLIGHT_BLITZ_ATF435.hex；同一块板、同一份配置下 9.1.0 正常。报告人写下一句「这个 target 上不要用 rc1 飞」。9
• 证据层级：一级。同一块板上多组构建的对照，附 _ebss 到 _estack 的剩余字节数和 IMU 数据结构落在栈顶下的深度：9.1.0 剩 19848 B、数据结构在栈顶下 21.6 KB，IMU 工作；rc1 只剩 2764 B、数据结构落在栈顶下 4.5 KB，IMU 冻结；rc1 去掉 USE_BOOTLOG 剩 4812 B，IMU 工作；再去掉 MAVLink 遥测剩 15008 B，同样工作。报告人另外给出 14 个 AT32F43x target 的剩余空间表，最小的 JHEMCUF435 只剩 1916 B。
• 责任分层：平台配置与固件。AT32 的链接脚本没有给主栈留真正的保留区，链接期只检查 .bss 之后 1.5 KB，溢出不会在编译时报出来；CLI 里的 Stack size 只查这 1 KB 窗口；AT32 的 spiTransfer() 超时返回的是错误计数、spiBusReadBuffer() 恒为真，SPI 读失败不会被上报成硬件故障。芯片和板级没有被指向。
• 复现与解决状态：2026-09-25 提出，2026-09-26 关闭为已完成。iNav 维护者回复 USE_BOOTLOG 本来就不该被定义、会立刻去掉，并加 CI 检查抓链接溢出；MAVLink 的上下文正在重做或删除。
• 待核实点：去掉 USE_BOOTLOG 之后的 10.0.0 构建有没有在 IFLIGHT_BLITZ_ATF435 上复测；剩余空间最小的那几个 target 是不是同样有风险；把 SPI 超时上报成读取失败的那支改动会不会合并。
• 原始链接：iNavFlight/inav Issue #12034（2026-09-25 提出，2026-09-26 关闭）

• 板卡与固件：Flywoo GOKU H743 Pro Mini Stack 45A，板上两颗 ICM42688P；报告人从 2025.12.x 升到 2026.6.1 之后出现，大约每三到四个起落出现一次。10
• 证据层级：一级。黑盒日志加一段飞行视频：飞了约 38 秒之后，roll 以一个约 15.37 度／秒的恒定速率往右漂、俯仰同时低头，回中摇杆也压不住；两颗陀螺的差值前 38 秒还在噪声范围内，之后分开，第二颗像是卡在 110 度／秒附近不再更新。
• 责任分层：板级与器件——报告人换掉整块飞控之后第二颗陀螺恢复正常，他自己判为硬件故障，旧飞控与那颗陀螺没有再单独测过。驱动与固件这一层也有份：双陀螺配置下第二颗失锁之后，固件继续使用它最后收到的那一帧数值，没有切回仍然正常的第一颗。
• 复现与解决状态：2026-09-20 提出，到本期仍开放。报告人换飞控后没有再复现；他同时更正了自己早先的一个判断——日志里同时出现的记录空档和陀螺漂移只是时间上撞在一起，空档后来还在，他怀疑是板载 flash 的写入速度跟不上采样率。
• 待核实点：换下来的那颗陀螺是不是真的坏了（缺一次独立测试）；触发它的是硬件本身，还是 2026.6.1 与 2025.12.x 之间的差异。
• 原始链接：betaflight/betaflight Issue #15724（2026-09-20，未关闭）

• 范围与整板型号：Betaflight 对 GD32F4 这一族（含 GD32F405／GD32F407）的平台支持。整板型号：未披露——两个改动都还没有绑定具体整板。
• 时间线：固件库那一支 Pull Request #14519 2025-07-07 提出，2025-11-16 被合并进 master，中间一度排在 2025.12.0 里程碑；平台源码那一支 Pull Request #14520 同一天提出，到本期仍然开放，2026-06-27 被移到 2026.12 里程碑。1112
• 证据层级：一级，两个改动请求的合并状态、里程碑和时间线都能在仓库里逐条核对。
• 责任分层：上游固件支持范围。固件库先进了主线，平台源码没有进，里程碑改期说明它没赶上 2026.6 这一版。
• 复现与解决状态：只进了一半。PR #14520 下的留言里，GigaDeviceSemiconductor 这个账号在 2025-12-18 询问能否在 12 月底前合并；2026-09-03 另一位贡献者说手上就有基于 GD32F4 的飞控硬件，愿意做测试，也愿意寄一块给审阅者。
• 待核实点：平台支持合并之后，GD32F4 什么时候进官方 target 列表和云端编译；现在跑着的 GD32F4 整板用的是厂商分支固件还是主线。
• 原始链接：betaflight/betaflight Pull Request #14519、Pull Request #14520

本期小结与下期优先核查项

1. 2026.6.x 的陀螺冻结：维护者说下一个版本有代码层面的修复，出来之后先看第 10 条的现象还在不在；同时确认 8 kHz PID 加双向下传 DShot600 是不是必要条件。
2. 第 11 条 MATEKH743 的片选按硬件版本怎么落，板厂有没有回应报告人和维护者的提问。
3. AT32F435：去掉 USE_BOOTLOG 之后的 iNav 10.0.0 构建在 IFLIGHT_BLITZ_ATF435 上的复测结果；剩余空间最小的那几个 target 是不是也中招。
4. GD32F4：平台支持是否进 2026.12，以及有没有整板跑在主线固件上的记录。
5. 上期第 7 条那笔修复进 2026.12 构建之后，AT32F435G／M 上 SPI ExpressLRS 的实际表现，以及 NewBeeDrone LIONBEE V1 的官方 config 有没有上线。