飞控芯片实用反馈：IMU与国产MCU首期基线

• 证据层级：一级是报告人自己的复现步骤和日志；二级是维护者或厂商版主给出的结论；三级是单方描述、没有可核对的材料。
• 责任分层：同一条现象要判它落在芯片、板级设计、驱动还是配置上，四层分开写。
• 时间：本期是基线期，收录此前没有记录过的一手材料，条数可以超过 5 条。从下一期起，每期最多 5 条新增，只收上一次发布之后新出现的条目；历史条目单列跟踪，标「历史」，跟到结案。
• 正负两面都收。帖子数量不用来推故障率，也不用来看份额，这两件事这份记录做不了。
• 封装和引脚相似不足以证明电气、朝向、软件或系统兼容。

历史条目跟踪

• 板卡与工况：OMNIBUS F4 V3，原 STM32F405 因 VDD 与 VSS 短路损坏；换上 GD32F405RGT6 后按住 boot 键上电。报告人核过引脚，两颗芯片一一对应，差别只在 STM32 那侧多接了两颗电容。1
• 固件：iNav，当时版本。
• 证据层级：一级，上板实测过程；另有维护者表态。
• 责任分层：驱动与固件适配。
• 状态：未解决。GD32 的 DFU 设备能出现在设备列表里，iNav 配置器认不到它。报告人比对过 STM32F4 与 GD32F4 的偏移地址，找不出差别，也没能解释 ST 的 HAL 为什么不适用（2022-11-01）。另一位参与者给的办法是全程用兆易的官方烧写工具，并说他每次用 iNav 配置器刷写，GD32 都起不来；换工具之后结果照旧（2022-11-18、2022-11-21）。同一帖里有人把 GD32F103CBT6 装进 CC3D 配 iNav 1.7.3 是可以正常工作的，维护者回复 F1、F3 的支持不会恢复。
• 待核实点：GD32F4 与 STM32F4 在时钟树和 USB 外设上的具体寄存器差异（帖内指向的两个 ChibiOS 论坛帖子是入口，没有展开）；以及有没有任何一块飞控在官方固件下真正跑通过 GD32F4。
• 原始链接：iNavFlight/inav Discussion #8455（开帖 2022-10-09，2023-11-22 之后仍有零星回复）

• 板卡与工况：Matek H743-SLIM V3 和 GEPRC GEP-F722-45A AIO V2，两块板都出现；USB 供电，静止几秒等陀螺校准，再手动晃动 10 到 30 秒，8 kHz 黑盒只记未滤波的陀螺与加速度计。2
• 固件：Betaflight 4.5-zulu，commit 1485438；另有人在 SPRacing H7RF 上用 4.3.0 复现。
• 证据层级：一级，两块板各自的黑盒日志加编号复现步骤，之后又补了第三块板的日志。
• 责任分层：器件特性与驱动配置相关，已有 AFSR 配置修复。H7RF 给陀螺做了单独的供电滤波，VDD 与 VDDIO 分开供电，Matek 板把两者并在一起，两种供电设计下波形一致，这个对照只缩小了供电设计的怀疑范围，不能据此完全排除供电。后来又有人在 H7RF 上分别装 ICM42605 和 ICM42688P 各测一次，两颗芯片都出现同样的平顶，把范围指向 ICM-426xx 这一族的行为。
• 状态：已解决。2023-10-23 由 PR #13132 关闭；同期有人在 EmuFlight 上提交了同一个改动，提交信息是「ICM426XX - Disable AFSR」，也就是把这条特性通过 AFSR 配置项关掉。
• 飞行层面的影响：报告人之一说，这台 H7RF 实际飞起来仍然很好，滤波在正常工作；滤波后的信号里没有这些尖峰。
• 待核实点：关掉 AFSR 之后对整条滤波链有没有人复测；ICM42605 是否也覆盖在同一个改动里。
• 原始链接：betaflight/betaflight Issue #12970（开帖 2023-07-19，结案 2023-10-23）

• 板卡与工况：NeutronRC AT32F435（20×20／30×30），target 用 NEUTRONRCF435SE；同帖还有一个 NeutronRC AT32/AM32 45A 的 AIO。实飞，bidir DShot 开或关都一样，中等油门匀速时更容易听出来。3
• 固件：Betaflight 4.5 nightly。
• 证据层级：一级，报告人自己的黑盒与视频，加上 7 项排除实验的逐条结果。
• 责任分层：板级设计与外设。报告人先怀疑 target，随后把飞控换成 Skystars F405HD2，抽搐消失。固定 48 kHz PWM、回退 BLHeli32 32.7、关掉动态怠速、换 Skystars AM32 电调，这四项都没有改变结果。维护者的结论是这类抽搐通常跟电调有关，也可能是陀螺本身故障，并提到陀螺的质量管控、安装位置和供电在飞控制造里容易出问题。
• 状态：2023-12-05 关闭为 completed，成因没有完全定下来。3 寸那台归到电调设置（把 PWM 固定在 48 kHz 就消失）；5 寸那台的根因没有被独立证实，关闭不等于拿到了板级结案的实证结论。对照实验里电调的固件版本、陀螺批次和具体工况，原帖没有披露。
• 待核实点：换不同批次的同型号陀螺之后是否还能复现；有没有人拿同 target 的 STM32 板做过对照。
• 原始链接：betaflight/betaflight Issue #13110（开帖 2023-10-08，结案 2023-12-05）

本期新增

• 范围：Betaflight 固件对 QMI8658 六轴器件的支持。
• 日期：2026-01-17 提出，2026-02-25 关闭，关闭原因标为 not planned。4
• 证据层级：一级，上游仓库里的请求原文与关闭状态。
• 责任分层：驱动与官方支持范围。
• 状态：已关闭，不计划实现。请求里给出的理由原文是「其它 IMU 太贵，只能选便宜的」。
• 待核实点：社区分支或第三方固件对 QMI8658 的实际支持程度，以及这类分支在采样率、滤波和驱动层跟官方固件的行为差异。
• 原始链接：betaflight/betaflight Issue #14885

• 影响面：所有把 BMI270 焊到为 ICM-42688-P 布局的板位上的板卡；改动是驱动的可选项，默认关闭，开关为 ENABLE_BMI270_ALIGN_AS_ICM。
• 日期：2026-07-25 提出，2026-07-28 合并。5
• 证据层级：一级，合并请求原文写明了封装关系，并指出改动覆盖四个原始读取路径。
• 责任分层：驱动层适配。
• 状态：已合并进 2026.6 里程碑。做法是在 BMI270 驱动里加一个顺时针 90° 的重映射，覆盖寄存器、DMA、FIFO 和加速度计四条读取路径。提交者写明这是过渡方案，顺时针 90° 还是 270° 仍要在实板上确认；长期方案是在探测时按器件读一张裸片朝向表。
• 待核实点：顺时针 90° 与 270° 的实板确认结果；同一个封装上 TDK 和 ST 的其它型号有没有同类朝向问题。
• 原始链接：betaflight/betaflight Pull Request #15484

• 板卡与固件：GREATMOUNTAINF435，MCU 为 AT32F435M；4.5.x 与 2025.12.x 两条线都失败。6
• 日期：2026-07-24 提出，2026-08-26 最后一次更新，到本期仍是开放状态。
• 证据层级：一级，报错回溯写在 issue 里，可以照着复现。
• 责任分层：驱动与构建配置。卡住的位置是 drivers/at32/bus_i2c_atbsp.c 和 bus_spi_at32bsp.c 在 warnings-as-errors 下编不过。
• 状态：未解决，issue 被 reopen 过。报告人写下的影响是：用户在配置器里走云端编译会拿不到固件，或者拿到缺驱动的固件，他举的例子是 ICM42688P 陀螺不工作。
• 待核实点：当前 master 上是否仍然复现；受影响的 AT32F435M 板卡范围有多大。
• 原始链接：betaflight/config Issue #1197

• 板卡与固件：AT32F435G、AT32F435M 两个平台头文件；发现场景是给 NewBeeDrone LIONBEE V1（AT32F435G，SPI 挂 SX1280）准备官方 config。7
• 日期：问题 2026-10-04 提出；修复同一天开出，2026-10-06 合并。8
• 证据层级：一级。平台头文件里的 #undef 行、提出时说明的场景、随后合并的修复，三者都能核对。
• 责任分层：平台配置与驱动。平台头文件里有 #undef USE_RX_SPI 和 #undef USE_RX_EXPRESSLRS，而平台头在板卡 config.h 之后引入，所以在 config 里定义也起不了作用；在编译参数里加 -DUSE_RX_SPI 同样会被后面的 #undef 覆盖。
• 状态：修复已合并。合并的改动同时在 LIONBEE V1 上做过测试，并让 AT32 的定时器在使能时产生一次 update event。
• 待核实点：修复进到放出固件的哪个版本；官方 config 什么时候上线；同文件里一并去掉的 PPM、PWM、CC2500 是否也放开。
• 原始链接：betaflight/betaflight Issue #15794 与 Pull Request #15797

• 板卡与工况：NeutronRC AT32F435 45A AIO V1.2，实飞使用。发帖人 2023-07-26 在 r/fpv 问这块飞控值不值得买，回帖人 2024-05-10 讲了自己的使用情况。9
• 固件：Betaflight 4.5 与 INAV 7.1。
• 证据层级：单方亲历描述，没有附日志、配置或复现步骤。
• 责任分层：没有故障可归因，只记录整板使用体验。
• 状态：使用正常。回帖人的原话是这块板在 BF4.5 和 iNav7.1 上跑得很好，不再需要 nightly 构建，连电脑的时候稍麻烦，之后就跟别的飞控一样。同一帖里另有一位用户报告在 BF4.5 上 get expresslrs 这类命令不被 CLI 识别、接收机页面的改动存不下来，回帖人判断是操作问题，而不是飞控或固件的问题。
• 不能拿来泛化：这是单条个人使用记录，能说明的是「存在能正常用的 AT32F435 整板」；既不用来推 AT32F435 的故障率，也不用来看份额。
• 待核实点：该帖共 17 条回复，本次只取到 8 条，其余 9 条未取到；发起者本人后续关于自用与 Mac 连接情况的说明在这些未取到的回复里，补到之后再收。
• 原始链接：r/fpv：NeutronRC AT32F435 AIO

• 板卡与工况：两块不同品牌的飞控，一块的 STM32F405RGT6 工作正常，另一块的同型号芯片损坏，提问者想直接对调。10
• 日期：2023-09-04。
• 证据层级：二级，ST 技术版主与社区资深成员在厂商论坛上的回复；提问者没有回报最终结果。
• 责任分层：芯片与板级维修。
• 状态：问答结束，没有后续。ST 技术版主给出的前提是好的那颗芯片没有被设成 RDP level 2，因为这一级别不可逆；他同时说明两颗芯片必须是同器件、同封装、同参数。另一位回复指出两块板的引脚分配和固件各不相同，需要准备对应固件，并给出 SWD 引脚（46 为 SWDIO、49 为 SWCLK）直连 ST-LINK 的接法。
• 待核实点：这块板换芯之后是否真的点亮；原板判「芯片损坏」的依据是什么。
• 原始链接：ST 社区 STM32F405RGT6 帖

本期小结与下期观察