把Cortex-M3落到M4复位序列的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
Cortex-M3排查时最怕只改表面现象，没有固定触发条件、现场记录和结果判断。
处理M4复位序列时先保留原始现象，再用最小复现动作确认问题是否真的被缩小。
当 STM32 芯片上电或按下复位键时，Cortex-M3/M4 内核并非从用户 main() 函数开始执行，而是遵循一套严格的硬件自动行为——复位序列（Reset Sequence）。这一序列是芯片启动的“第一行代码”，由内核硬件逻辑直接完成，不依赖任何软件指令。理解这一过程，是逆向分析启动流程、定位启动异常（如“跑飞”或“卡死”）的根基
在调试器（如 J-Link、ST-Link）中连接目标板后，先执行一次系统复位（SYSRESETREQ），然后单步执行到复位向量处，观察 SP 和 PC 的初始值。这是验证复位序列是否正确的标准入口动作
复位序列的核心动作只有两步：
0x00000000（或通过 VTOR 重映射后的基址）读取前 4 字节，作为主栈指针（MSP）的初始值0x00000004 读取后 4 字节，作为复位向量（Reset_Handler）的入口地址，并跳转执行这一过程在 Cortex-M3/M4 参考手册中被称为“向量表加载（Vector Table Loading）”。如果这两个地址中的任何一个指向无效区域（如未初始化的 Flash 或 RAM），芯片将立即进入 HardFault 或无法启动
要验证复位序列是否按预期工作，最直接的方法是使用调试器观察复位后的寄存器状态。以下是通过 J-Link Commander 或 IDE（如 Keil、IAR）进行验证的典型路径
复位后，SP 寄存器应等于向量表首地址指向的值。例如，若启动文件 startup_stm32f4xx.s 中定义的栈顶为 0x20020000（即 128KB SRAM 的末尾），则复位后 SP 必须显示为 0x20020000。如果观察到 SP 为 0x00000000 或随机值，说明向量表未被正确映射，或 Flash 起始地址的数据损坏
复位后 SP 值若等于启动文件定义的栈顶地址，则向量表首地址（0x00000000）的读取路径正常；否则，优先检查 Flash 的起始 4 字节是否被意外擦除或写入错误数据
复位后，PC 寄存器应指向复位向量（Reset_Handler）的地址。注意，Cortex-M3/M4 使用 Thumb 指令集，因此向量表中的地址最低位（LSB）必须为 1，以表示 Thumb 模式。例如，若 Reset_Handler 位于 0x08000100，则向量表中存储的值应为 0x08000101。复位后 PC 应显示为 0x08000100（硬件自动清除 LSB）
初学者常误以为复位后 PC 直接指向 main()。实际上，PC 先指向 Reset_Handler，由该函数完成时钟配置、变量初始化等操作后，才调用 main()。若 Reset_Handler 本身执行异常（如未正确设置 VTOR），PC 可能跳转到错误地址
root_cause 定位路径：当 SP 或 PC 异常时
如果复位后 SP 或 PC 的值与预期不符，可按以下路径定位根因：
0x08000000（STM32 默认 Flash 起始地址）的前 8 字节。若内容全为 0xFF 或 0x00，说明 Flash 未编程或已被擦除0x08010000）。此时复位序列读取的是 VTOR 指向的新向量表，而非默认的 0x00000000。检查 SCB->VTOR 的值是否与预期一致startup_stm32f4xx.s 中的栈大小定义和向量表布局。栈顶地址必须与芯片 SRAM 大小匹配（例如 STM32F407 的 SRAM 为 128KB，栈顶应为 0x20020000）以下表格可作为每次调试启动流程时的标准化检查工具，帮助快速区分硬件问题与软件配置问题
| 检查项 | 标准 | 是否通过 | 常见遗漏 |
|---|---|---|---|
| 复位后 SP 值 | 等于启动文件定义的栈顶地址（如 0x20020000 ） | □ 是 □ 否 | 未检查 Flash 首地址是否被 Bootloader… |
| 复位后 PC 值 | 指向 Reset_Handler 地址（如 0x080… | □ 是 □ 否 | 未确认向量表中地址 LSB 是否为 1 |
| Flash 首地址内容 | 前 4 字节为栈顶值，后 4 字节为复位向量值 | □ 是 □ 否 | 未区分 Flash 与 RAM 映射地址 |
| VTOR 寄存器值 | 若使用 Bootloader，VTOR 应指向新向量表… | □ 是 □ 否 | 未在 Reset_Handler 中尽早设置 VTOR |
某工业控制器项目使用 STM32F407，量产 500 片后出现约 5% 的“上电后无响应”故障。通过调试器捕获复位后 SP 值，发现异常芯片的 SP 为 0xFFFFFFFF。进一步检查 Flash 首地址，发现前 4 字节被意外擦除。根因是 Bootloader 在升级固件时未正确校验 Flash 写入完整性，导致向量表损坏。修复动作：在 Bootloader 的写入流程中加入 CRC 校验，并在跳转前验证向量表首地址的合法性
继续推进Cortex-M3时，先把Cortex-M3对应到工程结构中的入口、依赖和输出，再确认结果材料能不能复现当前结果。如果Cortex-M3/M4或复位序列与栈指针初始化验证变化，下一步不是马上改代码，而是先补一条最小验证，观察可观察信号是否还能说明目标达成。交接材料应写清可保留部分、可替换部分和优先复查位置，让项目能从本节自然进入下一轮迭代。遇到相邻章节结论冲突时，不直接替换答案，先对照Cortex-M3与可运行材料，再确认Cortex-M3/M4记录的是原因、过程还是结果。第02节的复盘出口是复位序列与栈指针初始化验证，它要能说明Cortex-M3、源码结构和可运行材料之间哪一项先发生变化。