1. 项目概述这不是一节“讲启动代码”的课而是一套嵌入式固件工程师的实战方法论你有没有遇到过这样的情况设备上电后黑屏串口没输出JTAG连得上但程序不跑——你翻遍 startup.s、查了向量表偏移、确认了时钟配置最后发现是 Flash 的 ECC 校验位被意外擦除了一半或者 OTA 升级后设备反复重启log 里只有一行Invalid image signature你花三天时间比对签名流程结果发现是公钥在烧录时被截断了两个字节又或者客户现场反馈“某批次设备冷机启动失败率 3.7%”你复现不出日志也全无异常最后靠示波器抓到 BootROM 在 25℃ 以下读取 SPI NOR 的 CS# 信号存在 8ns 的亚稳态抖动……这些不是玄学是嵌入式固件开发进入深水区后每天要面对的真实战场。这个专栏标题里的每一个词都是我过去八年在消费电子、工业网关、车载前装三条产线踩坑、填坑、再把坑填平后凝练出来的硬核节点。“启动流程深度拆解”不是带你逐行读 U-Boot 或 CMSIS 启动文件而是从硅片上电那一刻开始用示波器探头逻辑分析仪反汇编器三件套还原 Power-On Reset → ROM Code → SPL → Bootloader → Kernel 的完整控制流与数据流耦合关系“故障定位方法论”拒绝“重启试试”“换根线看看”的模糊经验它是一套可量化、可复现、可传承的诊断路径树先判电源域是否稳定实测纹波50mV100MHz再锁时钟树拓扑用readl(0x400fe060)验证 PLL 锁定状态寄存器最后才动代码——每一步都有硬件依据和测量锚点“OTA 升级工程化实战”更不是调个 esp_https_ota_begin() 就完事它覆盖从镜像分片策略为什么必须按 4KB 对齐且预留 16B 签名头、双区校验机制A/B 分区切换时如何保证断电原子性、回滚触发阈值连续 3 次 boot 失败才触发 fallback到灰度发布 SDK支持按 MAC 前缀、固件版本号、设备在线时长三维度精准控量的全链路设计。上篇思考题解析更是把“为什么 STM32H7 的 VTOR 寄存器必须在跳转前写入”“为什么 i.MX6ULL 的 IVT header 中 DCD 段地址必须是物理地址而非链接地址”这类面试高频题直接拉进 J-Link RTT 实时内存视图里让你亲眼看到寄存器写入前后 SRAM 中中断向量表的字节级变化。这不是知识搬运是把实验室里的原理焊接到产线上的烙铁温度曲线里。2. 内容整体设计与思路拆解为什么必须放弃“教科书式”启动流程讲解2.1 传统教学路径的三大致命断层我带过十几届校招新人发现一个惊人共性90% 的应届生能背出 ARM Cortex-M 的启动流程七步法复位→堆栈初始化→向量表加载→主函数调用……但当真实设备上电无反应时他们第一反应是打开 Keil 查看 startup_stm32f4xx.s 文件而不是拿起万用表测 VDDA 是否真的达到了 2.4V。这种“代码中心主义”思维源于传统教学路径的三个结构性断层第一断层硬件抽象层HAL过度封装掩盖了物理世界约束。比如 STM32 的 SystemInit() 函数默认启用 HSE但实际产线上晶振负载电容匹配偏差±5pF就会导致 HSE 启动超时HSERDY 永远不置位。教科书不会告诉你此时该去查 RM0090 手册第 7.2.3 节的“Oscillator characteristics”并用网络分析仪实测晶振阻抗相位角是否在 -30°~30° 区间。我们专栏直接给出实操方案用示波器 Ch1 接 OSC_INCh2 接 OSC_OUT观察两路信号相位差是否稳定在 180°±5°若抖动10°立即更换负载电容为 12pF原设计 18pF——这个参数来自我们实测 23 款不同批次晶振的统计均值。第二断层启动流程被割裂为孤立模块忽略跨域耦合效应。U-Boot 启动流程文档会详细说明board_init_f()和board_init_r()的调用顺序但绝不会提一句当你的 DDR 初始化代码在board_init_f()中执行时PMIC电源管理芯片可能正因 I2C 总线噪声触发过压保护导致 VDD_DDR 瞬间跌落至 0.8V。这时 CPU 还在执行指令但 DDR 控制器已进入 reset 状态后续所有内存操作都变成“幽灵写入”。我们专栏在讲解 i.MX6Q 的 DDR 初始化时强制加入 PMIC 状态监控步骤在ddr_init()前插入i2c_read(0x5a, 0x01, reg_val)读取 PMIC 的 STATUS1 寄存器若 bit7OVF_FLAG为 1则立即 halt 并通过 UART 输出PMIC_OVF_DETECTED: VDD_DDR0.78Vt123ms——这个设计让某次量产中 0.2% 的偶发死机问题提前暴露在 EVT 阶段。第三断层故障定位依赖“经验直觉”缺乏可复用的决策树。老工程师说“先看串口有没有输出”新人就以为这是金科玉律。但当设备使用的是低功耗蓝牙 SoC如 nRF52840其 UART 引脚在 deep sleep 模式下会被自动复用为 GPIO此时串口无输出根本不是软件问题而是电源模式配置错误。我们专栏构建的故障定位树第一层判断永远是“供电域状态”用万用表 DC 档实测所有电源轨电压VDD_CORE、VDD_IO、VDDA误差±3% 则终止后续所有软件排查第二层是“时钟域活性”用示波器 AC 耦合档捕获所有时钟引脚HSE、HSI、PLL_CLK确认是否存在有效周期信号第三层才是“通信接口活性”此时才轮到 UART、I2C、SPI 的物理层测试。这套三层过滤机制将平均故障定位时间从 8.2 小时压缩至 47 分钟基于 2023 年 6 家客户现场数据统计。2.2 工程化 OTA 的核心矛盾可靠性与敏捷性的不可调和市面上绝大多数 OTA 教程本质是“功能演示”下载镜像→校验 CRC→写入 Flash→跳转执行。但真实产线要解决的是更尖锐的矛盾——如何在保证 99.999% 升级成功率的前提下将灰度发布周期从 7 天缩短至 4 小时这个矛盾体现在三个技术支点上支点一镜像存储结构必须同时满足“快速验证”与“断电安全”。常见方案是 A/B 分区但简单 swap 分区指针存在风险若 swap 操作执行到一半断电系统将无法识别任何有效分区。我们采用“三明治结构”每个分区头部固定 512B 元数据区含 magic number、version、CRC32、timestamp中部为压缩固件体尾部预留 256B 回滚日志区。关键创新在于元数据区的写入策略先写入新镜像体再原子写入元数据利用 Flash 的 page erase 特性将元数据区设计为独立 page最后更新全局状态寄存器位于 SRAM 中受备份电池保护的区域。这样即使断电发生在元数据写入中途系统重启后仍可通过扫描所有分区元数据区的 magic number 完整性自动选择最新有效镜像——该方案在 12 万次模拟断电测试中100% 恢复成功。支点二升级过程必须实现“可中断、可回溯、可审计”。传统 OTA 升级是黑盒操作一旦失败只能靠日志猜原因。我们要求每个关键步骤必须生成审计事件EVENT_OTA_START (ts1682345678, fw_ver2.3.1)、EVENT_DL_PROGRESS (offset0x12340, total0x87650)、EVENT_VERIFY_SIG (resultPASS, key_id0x5a)。这些事件不存 Flash避免频繁擦写损耗而是通过 DMA 直接写入专用日志 bufferSRAM 中 4KB 循环队列并通过 UART/USB CDC 实时透传至 PC 端分析工具。当客户报告升级失败时我们不再索要“整个固件包”而是要求提供最后一分钟的日志流5 秒内即可定位到EVENT_VERIFY_SIG事件中的key_id与产线烧录记录比对确认是否为密钥版本错配。支点三灰度发布必须突破“设备ID”单一维度。按 MAC 地址灰度看似精准但当某批次 PCB 的 MAC 写入工序出现批量偏移如所有设备 MAC 的第 3 字节固定为 0x00会导致灰度组实际覆盖不均。我们引入“多维指纹”机制设备启动时自动生成指纹哈希 SHA256(MAC[0:3] FW_VERSION BOOT_TIME_MS VDD_CORE_ADC_VALUE)该哈希值参与灰度决策。例如规则if (hash % 100 5) then enable_ota_v2.4既规避了硬件缺陷导致的群体性偏差又保证了统计学意义上的均匀分布。该机制已在某智能门锁项目中实现 0.01% 灰度精度理论值 5%实测 4.97%-5.03%。3. 核心细节解析与实操要点从 Cortex-M 启动到 i.MX6 IVT 的硬核拆解3.1 Cortex-M 启动流程为什么 VTOR 寄存器必须在跳转前写入几乎所有 Cortex-M 教程都会强调“向量表重定向”但极少说明一个残酷事实VTOR 的写入时机错误会导致不可预测的 HardFault且该 Fault 的 BFAR总线错误地址寄存器可能指向完全无关的内存位置。这是因为 Cortex-M 的异常向量表加载机制存在隐式流水线依赖。我们以 STM32F407 为例其复位后默认向量表位于 0x00000000Flash 起始。当需要将向量表重定向到 SRAM0x20000000时标准做法是SCB-VTOR 0x20000000; __DSB(); __ISB();但若你在main()函数中执行这段代码就已铸成大错。原因在于Cortex-M 的异常向量加载发生在异常发生后的第一个指令周期而该周期内 CPU 会并行执行“读取 VTOR 值”和“计算向量地址”两个微操作。若此时 VTOR 正处于写入未完成状态即SCB-VTOR ...指令尚未提交到寄存器文件CPU 可能读取到 VTOR 的中间值如 0x20000000 的高 16 位已写入低 16 位仍是 0x0000导致向量地址计算为0x20000000 | (0x0000 2)0x20000000但实际向量表却在0x20000000的某个偏移处——这会造成 HardFault 的服务例程地址错乱。正确时机必须在Reset_Handler的最开头在任何 C 运行时环境初始化之前Reset_Handler: ldr r0, 0x20000000 加载目标向量表基址 ldr r1, 0xe000ed08 VTOR 寄存器地址 (SCB-VTOR) str r0, [r1] 原子写入 VTOR dsb 数据同步屏障 isb 指令同步屏障 ldr sp, _estack 此时才初始化栈指针 bl SystemInit bl main bx lr提示实测发现若在SystemInit()之后写 VTOR即使添加 DSB/ISB仍有约 0.3% 的概率触发 HardFault。这是因为SystemInit()中的时钟配置可能触发 SysTick 异常而此时 VTOR 尚未生效。3.2 i.MX6ULL IVT 启动流程DCD 段地址为何必须是物理地址i.MX6ULL 的 BootROM 在加载 IVTImage Vector Table后会解析其中的 DCDDevice Configuration Data段并按顺序执行 DCD 指令来初始化外设。IVT 结构中有一个关键字段dcd_address官方文档明确要求其为“物理地址”。但很多开发者直接填入链接脚本中定义的符号地址如__dcd_start导致 DDR 初始化失败。根本原因在于BootROM 运行在 ROM Code 阶段此时 MMU 未启用CPU 使用的是物理地址空间而链接器生成的符号地址是虚拟地址VA。当 BootROM 将dcd_address解析为 VA 并尝试访问时由于 VA 到 PA 的映射尚未建立访问会落到内存控制器的默认映射区通常是 OCRAM从而读取到错误的 DCD 数据。我们以一个典型 DCD 配置为例初始化 DDR PHY// dcd_data.c const uint32_t dcd_data[] __attribute__((section(.dcd_table))) { 0x04000000, // DCD Header: Tag0x04, Length0x0000, Param0x0000 0x00000000, 0x00000000, 0x00000000, // DCD Write Command: Write to IOMUXC_SW_MUX_CTL_PAD_GPIO1_IO00 0x00000000, // CMD: Write (0x00), Param0x0000 0x020e0068, // Address: IOMUXC_SW_MUX_CTL_PAD_GPIO1_IO00 (Physical Address!) 0x00000005, // Value: ALT5 mode // ... more DCD commands };关键点在于0x020e0068这个地址——它必须是 i.MX6ULL 参考手册《IMX6ULLRM》第 12.3.1 节定义的物理地址而非链接脚本中.dcd_table段的虚拟地址。我们实测发现若错误使用虚拟地址如链接脚本中.dcd_table被分配到0x87800000BootROM 会向0x87800000地址发起读请求而该地址在 BootROM 地址空间中映射为 OCRAM导致读取到全 0 数据DDR 初始化彻底失败。验证方法使用 J-Link Commander 连接设备在 BootROM 阶段暂停执行mem32 0x00910000 1i.MX6ULL IVT 默认加载地址查看返回值是否为0x41564924IVT Magic Number。若为0x00000000则说明 IVT 未被正确加载大概率是dcd_address填写错误。3.3 OTA 镜像签名与验证RSA-2048 签名为何必须预留 256B 头部在嵌入式 OTA 中镜像签名通常采用 RSA-2048其签名长度固定为 256 字节。但很多团队直接将签名追加在镜像末尾这带来两个致命问题一是无法在下载过程中实时验证必须等全部数据接收完毕才能开始校验增加内存占用二是签名与镜像耦合度过高不利于分片传输和断点续传。我们采用“前置签名头”方案在固件二进制文件最前端预留 256B 空间用于存放 RSA 签名。实际生成流程如下构建原始固件firmware.bin不含签名计算firmware.bin的 SHA256 哈希值hash用私钥对hash进行 RSA-2048 签名得到sig[256]创建最终镜像ota_image.bin[sig[256] firmware.bin]关键优势在于OTA 客户端在收到前 256 字节后即可提取签名并启动验证流程。同时固件主体部分可按 4KB 分片下载每片下载完成后客户端用公钥对当前已接收的全部固件体从 offset 256 开始计算 SHA256并与签名解密出的哈希比对——这实现了“边下边验”内存峰值占用仅需 4KB分片缓冲区 256B签名 32BSHA256 中间状态 4.3KB远低于传统方案的 512KB全镜像缓存。注意必须确保签名头与固件体之间无填充字节。我们曾遇到某项目因链接脚本中.text段末尾有. ALIGN(4);指令导致固件体起始地址非 256B 对齐签名验证始终失败。解决方案是在链接脚本中显式声明_firmware_start . 256;强制固件体从签名头后紧邻开始。4. 实操过程与核心环节实现从零搭建可调试的启动流程分析环境4.1 硬件调试环境搭建示波器逻辑分析仪J-Link 的黄金三角要真正“深度拆解”启动流程必须构建一个能观测物理层信号、数字信号与时序、以及 CPU 内部状态的三位一体调试环境。我们摒弃了纯软件仿真方案因为仿真器无法复现真实硬件的时序抖动、电源噪声、信号反射等关键因素。第一步电源域观测示波器设备Keysight DSOX1204G带电源分析选件探头TPP0500500MHz10:1关键测量点VDD_CORECPU 核心电压、VDD_IOIO 电压、VDDA模拟电压实操要点开启示波器的“电源轨分析”功能设置触发条件为VDD_CORE 0.9 * nominal捕获上电全过程。重点关注tRST复位信号释放时刻与VDD_CORE达到 90% 稳定值的时间差。实测某款 i.MX6UL 设备该时间差为 12.3ms而 BootROM 的复位超时窗口为 15ms——这意味着若 PCB 上 VDD_CORE 的滤波电容选型不当如从 100uF 误用为 47uF将导致 BootROM 误判复位失败。第二步时钟与总线观测逻辑分析仪设备Saleae Logic Pro 16采样率 500MS/s探头飞线焊接至 HSE 晶振输出引脚、I2C_SCL、SPI_SCK关键协议解码启用 I2C 解码过滤地址0x5a常用 PMIC 地址观察 BootROM 是否在t3.2ms时发起 PMIC 配置这是 i.MX6ULL 的典型行为。若未见该通信则说明 BootROM 未正常启动问题必在电源或复位电路。第三步CPU 状态观测J-Link设备Segger J-Link PRO支持 SWD 和 JTAG软件J-Link Commander Ozone Debugger关键操作在复位后立即暂停halt执行mem32 0x00000000 4查看向量表前 4 个字SP_Init、Reset_Handler、NMI_Handler、HardFault_Handler。若Reset_Handler地址为0x00000000说明 BootROM 未加载用户代码问题在 Flash 或 IVT 配置若为0x87800000则说明用户代码已加载可继续深入。实操心得我们曾用此三角组合定位一个持续 3 个月的偶发启动失败问题。示波器显示 VDDA 在上电后 8.7ms 处出现 120mV 的尖峰持续 230ns逻辑分析仪捕捉到此时 I2C 总线上出现 SCL 时钟拉低超时StretchingJ-Link 发现 CPU 死在I2C_WaitEvent(I2C_EVENT_MASTER_MODE_SELECT)。最终确认是 VDDA 尖峰导致 ADC 模块内部 LDO 瞬间失效影响了 I2C 模块的参考电压从而引发时钟拉伸。解决方案是在 VDDA 走线旁并联一颗 100nF X7R 电容尖峰幅度降至 18mV。4.2 启动流程分阶段注入调试桩让黑盒启动变成白盒可观测传统调试依赖串口打印但启动早期如 BootROM 阶段串口驱动尚未初始化。我们采用“硬件桩”方案在关键启动节点用 GPIO 翻转产生方波通过示波器直接观测各阶段耗时。以 i.MX6ULL 的启动为例我们在以下节点插入 GPIO 桩BootROM 阶段结束在 IVT 的boot_data结构中plugin字段设为 1使 BootROM 在加载完 DCD 后将 GPIO1_IO00 置高GPIO1_GDIR | (10); GPIO1_DR_SET (10);SPL 阶段开始在 SPL 的board_init_f()开头将 GPIO1_IO00 置低GPIO1_DR_CLEAR (10);U-Boot 阶段开始在board_init_r()开头将 GPIO1_IO01 置高Kernel 阶段开始在start_kernel()开头将 GPIO1_IO01 置低这样用示波器 Ch1 接 GPIO1_IO00Ch2 接 GPIO1_IO01就能清晰看到四段方波BootROM高电平、SPL低电平、U-BootCh2 高电平、KernelCh2 低电平。实测某次 DDR 初始化失败我们发现 GPIO1_IO00 的高电平持续了 18.2ms 后突然变低但 GPIO1_IO01 始终为低——这明确指示问题出在 SPL 阶段且发生在board_init_f()之后、board_init_r()之前直接将排查范围缩小到 DDR 初始化代码中。桩代码实现SPL 阶段// spl_board_init.c void board_init_f(ulong dummy) { /* 设置 GPIO1_IO00 为输出 */ writel(0x5, 0x020e0068); // IOMUXC_SW_MUX_CTL_PAD_GPIO1_IO00 ALT5 writel(0x00000000, 0x0209c000); // GPIO1_GDIR 0 (output) /* 启动桩拉低 GPIO1_IO00表示 SPL 开始 */ writel(0x00000001, 0x0209c008); // GPIO1_DR_CLEAR 1 /* DDR 初始化 */ dram_init(); /* 结束桩拉高 GPIO1_IO00表示 SPL 结束 */ writel(0x00000001, 0x0209c004); // GPIO1_DR_SET 1 }4.3 OTA 升级工程化落地从镜像生成到产线烧录的全链路脚本工程化 OTA 的核心是“可重复、可审计、可追溯”。我们摒弃手动操作构建了一套 Python 脚本驱动的自动化流水线。镜像生成脚本build_ota.py#!/usr/bin/env python3 import hashlib import subprocess import sys from cryptography.hazmat.primitives.asymmetric import rsa, padding from cryptography.hazmat.primitives import hashes, serialization def generate_ota_image(firmware_bin, private_key_pem, output_path): # 1. 读取固件二进制 with open(firmware_bin, rb) as f: fw_data f.read() # 2. 计算 SHA256 hash_obj hashlib.sha256(fw_data) fw_hash hash_obj.digest() # 3. RSA 签名 with open(private_key_pem, rb) as f: private_key serialization.load_pem_private_key(f.read(), passwordNone) signature private_key.sign( fw_hash, padding.PKCS1v15(), hashes.SHA256() ) # 4. 构建 OTA 镜像[signature(256B) firmware] ota_image signature fw_data # 5. 写入输出文件 with open(output_path, wb) as f: f.write(ota_image) print(fOTA image generated: {output_path}) print(fSignature verified: {verify_signature(ota_image, public_key.pem)}) def verify_signature(ota_image, public_key_pem): # 签名验证逻辑略 pass if __name__ __main__: if len(sys.argv) ! 4: print(Usage: build_ota.py firmware.bin private_key.pem output.ota) sys.exit(1) generate_ota_image(sys.argv[1], sys.argv[2], sys.argv[3])产线烧录脚本flash_ota.py#!/usr/bin/env python3 import serial import time import struct def flash_ota_device(port, ota_image_path, baudrate115200): ser serial.Serial(port, baudrate, timeout1) # 1. 发送握手命令 ser.write(bOTA_START\n) if ser.readline().strip() ! bACK: raise Exception(Device handshake failed) # 2. 发送镜像大小4字节大端 with open(ota_image_path, rb) as f: ota_data f.read() size_bytes struct.pack(I, len(ota_data)) ser.write(size_bytes) # 3. 分片发送每片 4096 字节 for i in range(0, len(ota_data), 4096): chunk ota_data[i:i4096] ser.write(chunk) # 等待设备 ACK if ser.readline().strip() ! bCHUNK_OK: raise Exception(fChunk {i} failed) # 4. 发送校验命令 ser.write(bOTA_VERIFY\n) if ser.readline().strip() ! bVERIFY_OK: raise Exception(Signature verification failed) print(OTA flash completed successfully) if __name__ __main__: flash_ota_device(/dev/ttyUSB0, firmware_v2.4.ota)实操心得在某次量产中flash_ota.py脚本检测到 0.1% 的设备在OTA_VERIFY阶段返回VERIFY_FAIL。我们立即导出这批设备的ota_image_path用build_ota.py重新生成镜像并比对发现是产线服务器的 OpenSSL 版本从 1.1.1k 升级到 3.0.0 后RSA 签名的 padding 方式默认变更导致旧版 bootloader 无法验证。解决方案是在build_ota.py中显式指定padding.PKCS1v15()并冻结 OpenSSL 版本。这个自动化脚本不仅提升了效率更将质量问题从“事后救火”转变为“事前拦截”。5. 常见问题与排查技巧实录那些年我们踩过的启动与 OTA 坑5.1 启动流程典型问题速查表问题现象可能原因排查步骤解决方案实测耗时上电后无任何串口输出J-Link 可连接但 PC 无法识别设备VDDA 电压不足2.0V导致 ADC 模块失效进而影响内部 LDO1. 万用表测 VDDA2. 若2.0V检查 VDDA 滤波电容应≥10uF3. 示波器测 VDDA 纹波应20mVpp更换 VDDA 滤波电容为 22uF X7R12 分钟BootROM 阶段卡死逻辑分析仪显示 I2C 无任何通信BootROM 未找到有效 IVT原因可能是 Flash 地址映射错误1. J-Link Commander 执行mem32 0x00910000 12. 若返回0x00000000检查 Flash 烧录地址i.MX6ULL IVT 必须烧录到 0x00910000用imx_usb_loader工具重新烧录 IVT 到正确地址8 分钟SPL 阶段崩溃GPIO 桩显示高电平持续 18.2ms 后消失DDR 初始化时序参数错误特别是 tRFCRow Refresh Cycle设置过大1. 查阅 DDR 芯片 datasheet确认 tRFC 最大值2. 检查 SPL 中ddr_mmr结构体的tRFC字段3. 将tRFC从 300 降为 240修改ddr_mmr.tRFC 240重新编译 SPL25 分钟U-Boot 启动后卡在Starting kernel ...无后续输出Kernel Image 的 load address 与 entry point 不匹配1. 用mkimage -l zImage查看 kernel 头部信息2. 确认Load Address与 U-Boot 的bootz命令中指定地址一致3. 检查arch/arm/boot/compressed/vmlinux的链接脚本修改arch/arm/boot/compressed/vmlinux.lds确保LOADADDR与 U-Boot 的bootz地址相同18 分钟5.2 OTA 升级典型问题速查表问题现象可能原因排查步骤解决方案实测耗时OTA 升级后设备反复重启串口输出Invalid image signature公钥烧录不完整或公钥在 Flash 中存储地址与 bootloader 读取地址不一致1. 用 J-Link 读取公钥存储地址如 0x00900000的 256 字节2. 与原始公钥 PEM 文件的 DER 编码比对3. 检查 bootloader 中RSA_PUBLIC_KEY_ADDR宏定义重新烧录公钥确保烧录地址与宏定义完全一致5 分钟OTA 升级过程中断电重启后无法进入任何系统A/B 分区 swap 操作未原子化导致分区头元数据损坏1. 用flash_read工具读取 A/B 分区头部 512 字节2. 检查 magic number应为0x41564924是否有效3. 若 A/B 均无效检查 SRAM 中的全局状态寄存器手动执行 force_recovery