飞控芯片实用反馈：SPI DMA 停摆、data-ready 改造与 AT32F435 的 SRAM 配置

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

历史条目跟踪

第 10 条｜Betaflight 2026.6.x 上陀螺与加速度计数据冻结（历史，关闭但未完全定因，本期两条线各走一步）

• 待核实点：2026.12 主线加 4K/DShot300 的飞行日志；第 20 条那处修复合并之后，这批冻结还复现不复现。
• 原始链接：betaflight/betaflight Pull Request #15860、betaflight/betaflight Issue #15854

第 18 条｜三处 DShot bitbang DMA 修复回移到 2026.6 分支（历史，有实测数据了，发布版仍没有）

• 待核实点：这 46.6 分钟是在 #15836 上飞出来的，与 #15859 是两支改动，合流之后还要再测一轮；2026.6 分支会不会真的出维护版。
• 原始链接：betaflight/betaflight Pull Request #15836（2026-10-13）、betaflight/betaflight Issue #15854、betaflight/betaflight Issue #15872（2026-10-19）

第 5 条｜BMI270 与 ICM-42688-P 共用封装但感应轴差 90°（历史，本期有一块板把这个开关打开了）

• 待核实点：见第 24 条；上期问的「顺时针 90° 还是 270° 的实板确认」仍然没有人贴出结果。
• 原始链接：betaflight/betaflight Pull Request #15843、betaflight/config Pull Request #1215

第 16 条｜LIONBEE V1 AIO（AT32F435G）的板级配置进评审（历史，仍是草稿）

• 待核实点：这块板上 USB 重新枚举的根因；三个批准之后能不能直接云端构建。
• 原始链接：betaflight/config Pull Request #1222（2026-10-05）

第 7 条｜AT32F435G／M 的官方固件把 SPI ExpressLRS 编译掉（历史，修复仍只在主线）

• 待核实点：2026.12 的构建出来之后，AT32F435G／M 上 SPI 挂 SX1280 的实际表现。
• 原始链接：betaflight/betaflight Releases、betaflight/betaflight Pull Request #15797

第 1 条｜GD32F405RGT6 焊上 STM32F405 的板位：能进 DFU，固件接不上（历史，仍未解决）

• 原始链接：iNavFlight/inav Discussion #8455（开帖 2022-10-09）

第 14 条｜Betaflight 的 GD32F4 平台支持（历史，仍在评审，这一周没有代码动作）

• 待核实点：GD32F4 有没有整板跑在主线固件上的记录；平台源码合并之后，什么时候进官方 target 列表和云端构建。
• 原始链接：betaflight/betaflight Pull Request #14520（2025-07-07）

其余 12 条的当前状态

本期新增

20｜陀螺读取卡死在一条被占住的 SPI 总线上：一次 DMA 传输错误就够了

• 对象与版本：Betaflight 的 SPI 驱动。改动是 PR #15859，2026-10-17 由 blckmn 提出，仍开放，挂着 Testing Required 标签。触发它的是前一天的 Issue #15854：SKYSTARSF7HDPRO，STM32F722，陀螺是 MPU6000 走 SPI1，固件 2026.6.2（提交 e0b7bb0）。10
• 工况：8 kHz 陀螺、8 kHz PID（pid_process_denom = 1），电机输出是 bitbang 双向 DShot600，黑盒写板载 SPI flash。陀螺 DMA 用 DMA2 的 0 号流收、5 号流发；DShot bitbang 用 2 号与 4 号流。
• 现象：飞行中陀螺与加速度计不再更新，未滤波的陀螺值冻结 528 ms 之后飞手上锁。拆掉桨在台架上能复现，接收机输入、电机输出和黑盒照常工作。同一块板在 4.5.2 与 4.5.3 上、同样频率同样协议都正常。报告人给台架加了仪表，录到 SPI DMA 传输错误，随后采集停止，而陀螺的 data-ready 中断还在照常触发。
• 改动写的机理：DMA 传输出错会关掉那条流，完成中断从此不来，SPI 总线就一直被占着。丢一个字节（SPI overrun）连错误标志都不置，结果一样；在 F4、F7、G4 上，没清掉的 overrun 会把此后收到的数据全部丢掉。
• 修法：打开传输错误中断，出错就中止这次传输并清掉 overrun；陀螺读取在 4 个采样之内没完成就放弃，交给下一次重来；status 里再加一个 SPI 错误计数，环境信息里也有独立的 SPI_ERRORS。
• 证据层级：一级。报告人的日志、台架仪表记录和 PR 的代码都能逐条核对。
• 责任分层：驱动。芯片这一层，F4／F7 的 SPI overrun 行为是既有机制，固件此前没有处理；板级设计这一层，SKYSTARSF7HDPRO 把陀螺放在 DMA2 的 0／5 号流、DShot 放在 2／4 号流，目前没有被指向；配置这一层，8 kHz 加 DShot600 是报告人的设置，但同一设置在 4.5.3 上正常。
• 复现与解决状态：报告人可以复现；修复方案已提交，没有合并；最新放出版本 2026.6.2 里没有这处改动。
• 一处容易读错的地方：本周另有人在 #15836（回移的三处 bitbang 修复）上飞了 46.6 分钟没出问题，那是第 18 条，两支改动不同，说明不了 #15859 的效果。
• 同期还有一份报告：FLYWOOF722PROV2，STM32F722 加 ICM42688P，固件 2026.6.2，约 8 kHz 陀螺与 PID、双向 DShot600，飞前改过磁罗盘配置，坠机后未滤波陀螺值在 21.744 秒停住。报告人自己写明，GPS 与罗盘只是猜测，那次飞行的黑盒 GPS 通道是关的，坠机后已拆机，事后看到的「GPS 未连接」不是飞行中的观测。这条按「疑似同一起因」记，不定因。
• 待核实点：2026.12 主线上还复现不复现；4K/DShot300 能不能避开；维护者问的「是不是只在 F722 上出现」还没有答案；AT32 的 SPI 驱动有没有同样的 overrun 处理。
• 原始链接：betaflight/betaflight Issue #15854（2026-10-16）、betaflight/betaflight Pull Request #15859（2026-10-17）

21｜iNav 把陀螺读取搬到 data-ready 中断上：F4 要用两条 DMA 流，还没有上板记录

• 对象与版本：iNav 的 PR #12065，作者 MrScothh，目标分支 next-10.1，开放，19 个提交、79 个文件、+352/−33，评审到 2026-10-22 仍在动。陀螺是 ICM426xx 系列，含 ICM-42688-P。11
• 改动：陀螺读取从主循环轮询改成按 data-ready 中断触发。先做了 H7，这一支推到 F4 与 F7；评审之后 gyro_data_ready = AUTO 成了默认值。F7 的 SPI FIFO 只有 4 字节，F4 一个字节都没有，所以每次 data-ready 读取要占两条 DMA 流；找不到中断脚、target 没声明引脚或没有空闲流时，回落到原来的轮询。
• 数字：作者在两块 F7 板上测到 GYRO 任务平均耗时从 12 µs 降到 3 µs。这两块板是 Flywoo F722 Pro V2（ICM-42688-P 在 SPI1，中断脚 PC3）和 Diatone Mamba F722 2022B（ICM-42688-P 在 SPI1，中断脚 PC4）。
• 作者自己写的风险：SPI 字节错位一位不会被自动发现，读出来的数值就是错的。他建议先过台架，数值不对就把 gyro_data_ready 设成 OFF。
• 证据层级：一级。提交与作者的两块实机记录都在；F4 那一段是二级，只有代码路径，没有上板。
• 责任分层：驱动。芯片这一层留下了约束：F4 没有 SPI FIFO，必须借两条 DMA 流，还要处理 F4 的 CCM-RAM 限制。配置这一层，这条路线成立的前提是每个 target 都声明了陀螺的中断脚，见第 23 条。
• 复现与解决状态：开放，未合并；F4 上没有任何一块实机跑过。
• 待核实点：F4 的台架数据；为了腾出流，ADC 可能要从 DMA2 的 0 号流挪到 4 号流，已经在用这两条流的板子会有什么反应；连续三次超时之后永久回落，会不会有人一直跑在回落路径上却不自知。
• 原始链接：iNavFlight/inav Pull Request #12065（2026-09-28 提出，2026-10-22 最后动作）

22｜AT32F435 的 SRAM 要在启动时改写芯片里的出厂配置位，这一版被维护者按住了

• 对象与版本：iNav 的 PR #11774，作者 sunyanmeng963，开放，11 条评审意见，2026-10-22 仍有动作。实机只有一块 BlueberryF435；作者说改动适用于所有 AT32 飞控。12
• 改动：在 system_at32f43x.c 里按链接脚本的 _SRAM_SIZE 和 TARGET_FLASH_SIZE 推出目标 SRAM 配置，跟芯片用户系统数据里的 eopb0 比；不一致就解 flash 锁、擦掉用户系统数据、写 eopb0、复位。链接脚本同时加上 _SRAM_SIZE = 192。
• 维护者问的第一件事是现象：PR 里没有描述，这块板原来按多少 SRAM 启动、这个问题是怎么发现的。第二件事更要紧：Reset_Handler 已经把栈指针设在 192 KB 的顶部，在 systemInit() 里重配 SRAM，有可能把栈一起擦掉，表现是停住或者砖化。他建议先用一个临时的安全栈指针，把这段挪到更早的位置。
• 自动评审另外提了三条：代码用的是 TARGET_FLASH_SIZE，多数 AT32 target 只定义 MCU_FLASH_SIZE，CI 已经在 SAGEATF4 上报了 -Werror=return-type；擦写的返回值没检查却无条件复位，失败时会变成复位循环；整段擦用户系统数据会带走 eopb0 以外的字段。
• 证据层级：代码与 CI 结果是一级；现象那一段是三级，提交者没有描述症状。
• 责任分层：驱动与平台。芯片这一层是 AT32F435 的 SRAM 分区由用户系统数据里的 eopb0 决定，这是机制，没有人做错；改动要处理的是固件在什么时候、用什么顺序去改这个值。
• 复现与解决状态：开放，未合并；一块板试过，没有症状记录。
• 待核实点：出厂板上的 eopb0 到底是什么值；重配 SRAM 与设置栈指针的先后顺序怎么排才安全；其他 AT32 板是不是也需要同样的设置。
• 原始链接：iNavFlight/inav Pull Request #11774（2026-08-11 提出，2026-10-22 最后动作）

23｜ACCTON_GFF4（STM32F405RGT6）：陀螺的中断脚写在了驱动不会读的宏里

• 对象与版本：iNav 的 PR #11658，作者 RunnyCow，目标分支 maintenance-10.x，开放，66 个提交、+2605/−82，2026-10-20 仍有提交。整板 ACCTON_GFF4，MCU 是 STM32F405RGT6，陀螺 ICM42605 走 SPI1，CS 在 PA4，朝向 CW0，中断脚 PC15。固件版本：走 10.x 维护分支，具体版本未披露。13
• 这一条的本期材料是 2026-10-16 的一次提交 fd273c9，标题写得很直白：把 ICM42605 的中断脚改成驱动实际会读的名字。diff 只有一行：

-#define GYRO_1_EXTI_PIN PC15
+#define ICM42605_EXTI_PIN PC15

• 提交说明给的理由：这块板的 ICM42605 经 common_hardware.c 注册，那里取的是 ICM42605_EXTI_PIN；这颗陀螺不读 GYRO_1_EXTI_PIN，所以原来的定义被忽略，陀螺没有中断线。14
• 为什么值得单独记：中断线在不在，决定第 21 条那条 data-ready 路线走不走得通。引脚定义写错，固件会安静地回落到轮询，界面上看不出任何异常。这也是本频道追踪 STM32F405RGT6 以来第一块有具体板名的记录。
• 证据层级：一级。一次提交、一个 diff，宏名可以在驱动源码里对照。
• 责任分层：配置，具体是 target 定义。芯片与板级设计都没有被指向，错的是宏名。
• 复现与解决状态：改动已经进了 PR 分支，PR 未合并；没有上板记录。
• 待核实点：改完之后这块板的陀螺中断有没有真的响应；其他用 ICM42605 的 target 有没有同样写错；ACCTON_GFF4 什么时候合进维护分支。
• 原始链接：iNavFlight/inav Pull Request #11658（2026-10-20）、iNavFlight/inav commit fd273c9（2026-10-16）

24｜TUNERCF435 打开「BMI270 按 ICM 对齐」的开关，一块 AT32F435 的板子已经合并

• 对象与版本：betaflight/config 的 PR #1215，作者 TUNERC-Aria，2026-10-19 合并，改动一行：ENABLE_BMI270_ALIGN_AS_ICM 1。整板 TUNERCF435，MCU 是 AT32F435G；配置里 BMI270 的驱动与 ICM42688P 的 SPI 驱动同时开着，陀螺 CS 在 PA4、中断脚 PC13、走 SPI1。5
• 这一行的意思：这块板把 BMI270 按 ICM42688P 的朝向读，也就是板厂认为两种料在板上的贴装朝向一致。第 5 条讲过这个开关存在的理由——两颗料共用封装，感应轴差 90°。
• 证据层级：合并记录与 diff 是一级；朝向本身是三级。PR 描述里原理图评审、硬件抽测、飞行测试三项都没勾，自动评审也写明这块板上传感器的物理朝向未经验证。
• 责任分层：配置，具体是板级配置里的朝向。芯片没有被指向。
• 复现与解决状态：已合并，会进下一个构建；没有实板核对记录。
• 待核实点：装上 BMI270 与装上 ICM42688P 的两种来料，究竟是哪一种在飞、滚转方向对不对；如果两块料的实际朝向不同，这一行会让其中一种读错 90°。
• 原始链接：betaflight/config Pull Request #1215（2026-10-19 合并）

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

1. 第 20 条的正面与反面：2026.12 主线加 4K/DShot300 的飞行日志；#15859 有没有合并；冻结是不是只在 F722 上出现。
2. 第 21 条的 F4 数据：这条路线在 F4 上一次实板记录都没有；ADC 从 DMA2 的 0 号流迁走之后，已经在用这条流的板子会有什么反应。
3. 第 23 条：改完宏名以后陀螺中断有没有真的响应；其他用 ICM42605 的 target 有没有同样写错。
4. 第 22 条：AT32F435 出厂板上的 eopb0 实际值；重配 SRAM 与栈指针的先后顺序能不能改安全。
5. 两条攒下来的板级配置线索：FLYWOOF405 把 LED 灯带脚写成 PA8，与 USB 检测脚重合，也不在定时器映射里；JHEF7DUAL 第二颗陀螺的朝向在官方配置里是 CW90，厂商自己的 dump 写的却是 CW270。两条都还没有上板核对，留到下一期。