目标识别、备份、刷写与恢复¶

刷写会同时改变程序、默认参数、存储格式和外设支持。正确的固件项目但错误的板级目标，可能表现为传感器缺失、输出错误、USB失联，甚至无法启动。

固件身份与恢复链

先判断是否需要刷写¶

以下情况不要求立即刷写：

当前固件项目和板级目标正确；
当前版本仍受项目支持；
配置工具能够完整读取；
没有需要修复的已知问题；
当前参数和外设状态可以建立可靠基线。

“最新版”不是单独的刷写理由。升级会改变默认值、参数名称、功能行为和配置工具兼容范围。先阅读从当前版本到目标版本的全部迁移说明。

以下情况应停止使用当前固件并核验：

固件报告的目标与实物不符；
来源、版本或构建选项不可追溯；
配置工具出现不兼容告警；
传感器、存储或输出资源与板卡资料明显矛盾；
升级历史不明，且不存在修改前备份；
厂商定制固件包含标准发行版没有的资源映射。

三重目标识别¶

选择固件前必须让三类证据一致：

1. 实物身份¶

产品准确名称；
硬件修订号；
PCB丝印；
处理器封装；
板载传感器；
USB标识；
厂商原理图和目标说明。

2. 运行身份¶

当前固件项目；
当前版本和构建标识；
当前板级目标；
当前检测到的传感器；
当前输出和端口资源。

3. 发布身份¶

官方发布页；
目标文件名；
发布版本；
文件大小；
发布方提供的摘要；
下载文件自行计算的SHA-256。

三者不能一致时，不刷写。

备份不是一个文件¶

完整修改前基线至少包含：

类别	内容	用途
身份	飞控、硬件修订、固件、目标、工具版本	防止恢复到错误设备
可读配置	端口、机型、方向、模式和外设设置	人工审查和差异比较
完整参数	全量参数及其类型	重建同版本运行状态
默认差异	相对该版本默认值的变化	识别项目实际定制
校准数据	传感器、遥控、电池等校准值	判断是否可以迁移
运行状态	传感器发现、错误、解锁原因、资源状态	区分刷写前已有问题
固件产物	原固件文件或准确官方下载位置与哈希	回滚程序
恢复说明	进入引导/DFU/SWD的方法和成功标志	连接失败时可执行

截图便于人工查看，但不能代替可搜索、可比较的文本导出。反过来，参数文本也不能证明实体方向和接线。

不同平台的备份边界¶

Betaflight和INAV¶

保存官方工具导出的配置，并保留命令行接口（CLI，Command-Line Interface）中的版本、目标和差异输出。命令名称和输出范围必须以当前固件的帮助及官方文档为准。

CLI文本通常不是跨目标、跨项目或跨大版本的通用恢复镜像。恢复前应逐段审查资源、端口、传感器、输出和默认值变化。

ArduPilot¶

保存全部参数和可读参数列表，同时记录载具固件、板卡、参数元数据版本和地面站版本。参数文件不包含全部外部设备状态，也不能证明执行器接线。

不要把其他飞行器的参数文件直接写入新机。即使机架相同，传感器实例、方向、遥控端点、电池监视器和输出功能仍可能不同。

PX4¶

保存参数和飞控身份，记录QGroundControl版本、板级目标和v1.17.0固件来源。参数备份不能跨不兼容版本盲目导入；机型选择可能改变默认参数和启动模块。

备份的恢复分级¶

级别	允许内容	条件
A：只读比较	打开旧配置查看	不向飞控写入
B：同设备同版本	恢复明确的非校准设置	目标、版本和硬件完全一致
C：版本迁移	按发布说明逐项迁移	每项重新验证
D：更换硬件	只复用经审查的逻辑意图	校准、资源和方向重新建立
禁止	整包跨平台、跨目标或跨大版本写入	无安全依据

传感器偏置、电池比例、执行器端点和板级资源通常与具体硬件绑定，不应作为普通模板迁移。

固件产物控制¶

下载后记录：

来源URL：
发布日期：
固件项目：
版本：
提交：
目标：
文件名：
文件大小：
发布方摘要：
本地SHA-256：
下载日期：

如果发布方提供摘要或签名，应验证其来源和结果。只有自行计算摘要而没有可信发布值，只能用于之后确认文件未变化，不能单独证明来源可信。

受控刷写步骤¶

具体按钮和进入方式以当前板卡及平台官方文档为准，通用顺序为：

拆除螺旋桨并拍照；
完成修改前备份；
关闭会占用串口或USB设备的其他软件；
确认计算机不会休眠；
使用已验证的数据线和稳定接口；
核对目标、版本和固件文件摘要；
确认恢复工具和恢复入口已经可用；
只连接板卡资料允许的供电；
启动刷写并保存完整日志；
不在擦除、写入或校验阶段断电；
等待工具明确报告完成；
重新枚举并只读核对固件身份；
重新读取传感器和硬件错误；
导出刷写后空白或默认基线；
再开始逐项配置。

不要在刷写成功后立即导入全部旧参数。先证明新固件以正确目标正常启动。

擦除配置的选择¶

保留旧配置可能减少重复工作，也可能把已废弃参数、错误资源映射和不兼容默认值带入新版本。完全擦除可得到清晰基线，但会丢失校准和定制。

选择依据：

同一设备的小版本升级且官方明确支持迁移，可按发布说明保留；
项目切换、目标纠正、来源不明或跨大版本，优先建立干净基线；
任何情况下都先备份；
擦除后逐项恢复意图，不追求把旧文件“完整导入无报错”。

刷写后验证¶

至少确认：

固件项目、版本、提交或构建标识正确；
板级目标正确；
USB或通信端口稳定；
内置传感器数量和类型合理；
存储介质可用；
不存在持续复位；
当前机型和输出状态符合预期；
当前为未解锁状态；
旧配置尚未被无审查恢复；
修改前、刷写日志和刷写后基线均已保存。

恢复路径模板¶

先使用四平台恢复入口卡确定平台级入口，再用当前板卡硬件修订资料把下表填成具体动作。平台入口不能替代板卡的BOOT电平、焊盘、bootloader和写入地址。

每块板必须把下表填成具体动作：

项目	项目值
普通启动时USB标识	待填
引导加载模式进入方式	待填
设备固件升级模式（DFU，Device Firmware Upgrade）标识	待填
恢复按键或焊盘	待填
短接或按键时序	待填
恢复工具和版本	待填
正确恢复产物	待填
写入地址或工具自动规则	待填
成功标志	待填
失败停止条件	待填
串行线调试接口（SWD，Serial Wire Debug）位置	待填

“按住BOOT试试”不是恢复程序。不同板卡的按键电平、供电顺序、引导加载程序和写入地址可能不同。

恢复演练¶

恢复能力应在飞行器仍未安装螺旋桨时验证，至少做到：

能识别普通运行模式和恢复模式；
能退出恢复模式并重新正常启动；
能定位正确的已验证固件；
能说明何时使用普通引导恢复，何时升级到SWD；
不通过反复随机按键和插拔寻找入口。

没有必要故意中断一次真实刷写制造故障。演练入口、工具识别和恢复产物即可；故障注入应在替代板或专用实验中进行。

失败分支¶

工具找不到设备¶

依次检查：

数据线是否支持数据；
USB端口和系统枚举；
是否被其他软件占用；
普通模式与恢复模式是否混淆；
板卡允许的供电；
对应驱动或系统权限；
官方板卡恢复步骤。

不要同时改变线缆、驱动、按键时序和固件文件，否则无法定位原因。

写入完成但传感器缺失¶

首先怀疑目标、构建选项或硬件修订不匹配，不立即修改传感器驱动参数掩盖问题。对照刷写前传感器清单和板卡资料。

配置工具字段异常¶

停止写入，核对固件与工具兼容矩阵。字段为空、枚举错位或页面缺项可能是协议或元数据不兼容。

无法普通启动¶

保存刷写日志和USB枚举信息，进入已经验证的恢复路径。若恢复身份仍不明确，不继续尝试其他相似目标。

本篇放行条件¶

三重目标识别一致；
修改前基线完整；
固件来源、文件和摘要已记录；
已审查版本迁移说明；
刷写过程和结果有日志；
刷写后身份与预期一致；
未盲目导入旧配置；
恢复路径已经填写并完成入口演练；
螺旋桨仍未安装且解锁被禁止。

检查理解¶

为什么同为STM32F405的两块飞控不能共用同一个固件目标？
参数备份为什么不是完整恢复镜像？
为什么新固件首次启动后要先保存默认基线？
自行计算SHA-256能证明哪些事情，不能证明哪些事情？
为什么不建议故意中断真实刷写来验证恢复？