飞控芯片实用反馈：AT32F435 新料号、LIONBEE V1 板级配置与 F722 冻结的结案口径

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

历史条目跟踪

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

• 待核实点：GD32F4 换芯这件事在 2026 年有没有新的上板尝试；上游平台支持这一半的进展见第 14 条。
• 原始链接：iNavFlight/inav Discussion #8455

第 5 条｜BMI270 与 ICM-42688-P 共用封装但感应轴差 90°（历史，本期有新材料）

• 待核实点：上期问的「顺时针 90° 还是 270° 的实板确认」仍然没有人贴出结果；BMI423 这条改动也还没有实板记录。
• 原始链接：betaflight/betaflight Pull Request #15843

第 6 条｜GREATMOUNTAINF435 云端编译失败（历史，仍开放）

• 待核实点：RGT7 是单开一个 target，还是按硬件版本把 config 拆成两份。
• 原始链接：betaflight/config Issue #1197

第 7 条｜AT32F435G／M 的官方固件把 SPI ExpressLRS 编译掉（历史，问题帖已关闭，修复仍未放出）

• 待核实点：2026.12 的构建出来之后，AT32F435G／M 上 SPI 挂 SX1280 的实际表现；LIONBEE V1 的 config 合并后能不能直接云端构建。
• 原始链接：betaflight/betaflight Pull Request #15797、betaflight/betaflight Issue #15794、betaflight/betaflight Release 2026.6.2

第 10 条｜Betaflight 2026.6.x 上陀螺与加速度计数据冻结（历史，以建议配置结案，2026.x 上未验证）

• 待核实点：在 2026.x 上用 4 kHz PID 加 DShot300 复测的结果，目前没有任何人贴出过；2026.6 分支的下一个维护版会不会带上那三处 DMA 修复。
• 原始链接：betaflight/betaflight Issue #15816、betaflight/betaflight Issue #15815、betaflight/betaflight Issue #15783、betaflight/betaflight Pull Request #15779

第 11 条｜MATEKH743 的第二颗 ICM42688P 从来没被识别过（历史，仍开放）

• 待核实点：这块板的硬件版本号；官方 config 是按版本拆成两份，还是把 GYRO_2_CS_PIN 那一行统一改成 PE11；报告人提出的 gyro_init 三处改动会不会进后续版本。
• 原始链接：betaflight/betaflight Issue #15807

第 12 条｜iNav 10.0.0-rc1 在 AT32F435 上把 IMU 冻住：主栈溢出（历史，修复已进维护分支）

• 待核实点：这次合并有没有进 2026-09-29 放出的 10.0.0-rc2——那一版发布说明列的是 H7／F7 的 SPI 分频修正、EXTI 时序等约 26 项修复；剩下空间最小的那几个 AT32F43x target 需不需要同样的处理。
• 原始链接：iNavFlight/inav Issue #12034、iNavFlight/inav Pull Request #12040、iNavFlight/inav Pull Request #12047

第 13 条｜Flywoo GOKU H743 的第二颗 ICM42688P 中途失锁（历史，仍开放）

• 待核实点：换下来的那颗陀螺有没有单独测过；触发它的是硬件本身，还是 2026.6.1 与 2025.12.x 之间的差异。
• 原始链接：betaflight/betaflight Issue #15724

第 14 条｜Betaflight 的 GD32F4 平台支持（历史，仍在评审，同期另一族已进主线）

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

其余 5 条的当前状态

本期新增

15｜AT32F435 的两个新料号进上游评审：闪存 960 KB、页 4 KB，提交者称可以引脚直换

• 对象与版本：Betaflight 的 AT32F435 平台支持，涉及 AT32F435RPT7（LQFP64）与 AT32F435CPU7（QFN48）两个料号。整板型号：未披露，改动还没有绑定任何一块板。PR #15827（2026-10-12 提出，仍开放）18
• 提交者的说明：xP 系列相对 AT32F435xG，闪存调整为 960 KB、页大小调整为 4 KB，整体性能不变，外设与引脚 I/O 不变，因此现有产品可以引脚直换。
• 上游处理：2026-10-12 当天挂在 PLATFORM: AT32 标签下（先是误挂 APM32，随后改回），并加进 2026.12 里程碑；2026-10-13 作者把 master 合进分支，状态仍是开放。
• 证据层级：一级。改动、标签、里程碑在仓库里都能逐条核对；「引脚直换」这句是提交者的说法。
• 责任分层：平台支持（上游固件）。芯片本身没有被指向，这里是支持范围的问题。
• 待核实点：960 KB 闪存与 4 KB 页在链接脚本、配置存储与 DFU 流程里怎么处理；AD 与 iNav 侧会不会同步；有没有整板实机记录。
• 不能拿来泛化：引脚相同只说明同一份料表能用，够不够替换还要电气与固件两层的实板验证。
• 原始链接：betaflight/betaflight Pull Request #15827（2026-10-12）

16｜LIONBEE V1 AIO（AT32F435G）的板级配置进评审：ICM42688P 与 BMI270 共用一套板向，SPI2 挂 SX1280

• 对象与版本：betaflight/config 的 PR #1222，2026-10-05 提出，仍开放，最近一次更新 2026-10-10。整板是 NEBD 的 LIONBEE V1 AIO，MCU 为 AT32F435G。固件版本：未披露。19
• 配置内容：在 NEBD 厂商下新增 LIONBEE_V1；ICM42688P 与 BMI270 两颗陀螺共用一套板级朝向；SPI1 给陀螺、SPI2 给 SX1280 接收机、SPI3 给 flash 与 OSD／VTX；UART5 作 GPS，I2C2 给气压计与罗盘。
• 作者与评审：作者是维护者 nerdCopter。评审里已按 haslinghuis 的建议修正过罗盘驱动宏（当前名字是 USE_MAG_QMC5883L）、补上气压计／罗盘／USE_LED_STRIP／USE_GPS 的定义，并把 VTX 电源码的两只 PINIO 写清楚。
• 尚未证实的值：提交说明里写明，每个还没在硬件上验证过的值都带注释。
• 证据层级：一级。PR 的提交说明、评论与改动都能逐条核对。
• 责任分层：板级配置。陀螺、接收机、气压计都是板上的排布问题。
• 待核实点：这颗 AT32F435G 板子上第二颗陀螺与 SX1280 的实板验证；config 什么时候合并、合并后 2026.12 的云端构建能不能直接用（对上期第 7 条的待核实点）。
• 不能泛化：两颗陀螺靠一套板向定义覆盖，说明的是这块板的排布，够不上「两颗陀螺可以互换」的证据。
• 原始链接：betaflight/config Pull Request #1222（2026-10-05）

17｜iNav 在 AT32F43x 上的 SPI：分频注释与实跑速率不符，SPI4 支路另有缺陷，SD 卡初始化时钟超速

• 对象与版本：iNavFlight/inav 的 PR #12048，2026-09-27 提出，仍开放，带 Testing Required 标签；当天一度被关闭后重开。整板型号：未披露。20
• 第一处，注释里的速率是 F4 的：原来的注释写 10.5／21／42 MHz。AT32F43x 的 system_clock_config() 把 PLL 跑到 288 MHz、APB1 与 APB2 都除以 2，每条 SPI 实际分的是 144 MHz，也就是 9／18／36 MHz；SPI4 挂在 APB2 上的慢表，速率与 SPI2、SPI3 相同。这一处只改注释，不改速率。
• 第二处，只有 SPI4 的 target 编译不过：SPI4 用的慢分频表只在定义了 SPI2 或 SPI3 时才存在，SPI4_NSS_PIN 也没有 NONE 回退；即便编过，spiDeviceByInstance() 不认识 SPI4，spiSetSpeed() 与错误计数都不管它，总线会停在初始化时的分频上。目前没有 AT32 target 用 SPI4。
• 第三处，SD 卡初始化时钟超速：SPI_CLOCK_INITIALIZATON 是 144 MHz 除以 256，562.5 kHz，而 SD 卡在识别前最多只能给 400 kHz。AT32 要拿到 281.25 kHz 得同时写 ctrl2 的 mdiv_h 与 ctrl1 的 mdiv_l，原来的代码只写了 ctrl1。
• 同类问题的落点：H7／F7 上的分频修正 PR #12032 已经合并，并且出现在 2026-09-29 放出的 10.0.0-rc2 发布说明里（「SPI clock-divisor correction on H7/F7」）；AT32F43x 这一支还开着。21
• 证据层级：一级。三条都是提交说明加代码，可以逐条核对。
• 责任分层：驱动与平台配置。三处都是平台代码自己算错或写漏，芯片没有被指向。
• 待核实点：合并后在 AT32F43x 上挂 SD 卡的实际行为；SPI4 一旦有 target 使用，速率与错误计数会不会真的跟上。
• 原始链接：iNavFlight/inav Pull Request #12048（2026-09-27）

18｜三处 DShot bitbang DMA 修复回移到 2026.6 分支：一个宏少写括号清错了别人的标志位

• 对象与版本：Betaflight 的 PR #15836，2026-10-13 提出，仍开放，带 RN: BUGFIX 与 Testing Required 标签，挂 2026.6 里程碑。它回移的是三支已经合入主线的改动：PR #15538、#15539、#15682。22
• 第一处：telemetry 抓取不再被中途打断（#15538）。
• 第二处：重编程 DMA 流之前先等它停下来（#15539）。
• 第三处，也是最要命的一处：DMA_CLEAR_FLAG() 的宏参数没有加括号，A | B 被解析成 A | (B << shift)，只有一个标志位移到位，其余被原样写进低 6 位。对 flagsShift 为 22 的流，F4 的 DShot DMA 处理每帧都在清掉 0 号流的标志，自己该清的 FEIF／DMEIF／TEIF／HTIF 一直留着。同样的调用也出现在 SPI 驱动里，包括 AT32 用的 bus_spi_at32bsp.c。
• 同一个改动还堵住一处空中停摆：bbDMAIrqHandler() 遇到 DMA_IT_TEIF 时是 while (1) {};，而这些 target 上除 STM32N657 外没有看门狗。一次电机流上的 DMA 传输错误就足以让飞控在空中停住。现在它清标志并置 reinitRequired，由 bbUpdateComplete() 重载寄存器集后重试。
• 证据层级：一级。三处改动与代码都能逐条核对。
• 责任分层：驱动。AT32 侧是同一份 SPI 驱动里的共用缺陷。
• 复现与解决状态：PR 开放，待测试，没有合并；最新的放出版本仍是 2026.6.2，这三处修复不在任何放出固件里。
• 待核实点：这个掩码缺陷在 AT32 的 SPI 传输上多久出现一次，会不会表现为读回 0x00 之类的假故障；2026.6 分支会不会出维护版。
• 不能拿来泛化：目前还没有材料证明第 10 条那些飞行中冻结就是这处缺陷，两者只是同一套 DMA 代码里被点出来的问题。
• 原始链接：betaflight/betaflight Pull Request #15836（2026-10-13）

19｜AT32 飞控在 macOS 上多行粘贴 CLI 会损坏输入，同一块板子在 Windows 上正常

• 板卡与固件：AT32F435 的飞控，具体整板型号未披露；配置器版本 2026.6.2（091127c）。Issue #5552（2026-09-21 提出，仍开放）23
• 工况：在配置器的 CLI 里一次粘贴两行 vtxtable 命令；LF 与 CRLF 换行都试过，逐条键入正常。
• 现象：第一行被截断，第二行插进第一行中间，还有字符丢失或重排，CLI 报 TOO MANY FREQUENCIES 与 UNKNOWN COMMAND。
• 报告人的对照：macOS 加 AT32F435 损坏；同一台 Mac 加 STM32 正常；Windows 加同一块 AT32F435 正常。
• 证据层级：一级。四种组合的对照矩阵是报告人自己贴出来的，可复现。
• 责任分层：报告人明确说还没定位，候选是固件、AT32 的 USB CDC 实现，或配置器／WebSerial 这一路。芯片没有被指向。
• 这是一类老问题的新一例：AT32 飞控加 macOS 的组合在配置器仓库里出现过多次，2025-05-12 合并的 PR #4455 专门修过「AT32 在 macOS 上配置存不下来」。24
• 待核实点：损坏发生在 USB CDC 的哪一层；换个版本的配置器是否同样；有没有第二个人复现。
• 原始链接：betaflight/betaflight-configurator Issue #5552（2026-09-21）、betaflight/betaflight-configurator Pull Request #4455（2025-05-12 合并）

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

1. 第 10 条的正面验证：有没有人在 2026.x 上用 4 kHz PID 加 DShot300 飞出干净的黑盒日志。这是判断那条冻结到底属于配置余量还是固件缺陷的关键。
2. 第 18 条回移之后：2026.6 分支有没有出维护版，以及 DMA_CLEAR_FLAG 修好前后 AT32 的 SPI 错误计数有没有变化。
3. 第 15、16 条合并之后：AT32F435xP 的链接脚本与配置存储怎么落地；LIONBEE V1 的 config 合并后云端构建能不能直接用，SPI2 上的 SX1280 实际能不能通。
4. 第 17 条：AT32F43x 的 SPI 分频那一支合并后，SD 卡初始化与 SPI4 的复测结果。
5. 第 11、13 条这两条 IMU 侧的老账：MATEKH743 的硬件版本号与官方 config 的落法；Flywoo GOKU H743 换下来那颗陀螺的单独测试结果。