程序总要回答“第一条应用指令从哪里来”。在主机上，操作系统和 C 运行环境已经准备好进程，再把控制权交给 main；在嵌入式目标上，复位意味着处理器刚开始重新取得执行控制权，必须先遵循处理器规定的入口约定。若把两者混为一谈，就会把主机实验中的显式 main() 调用误认为硬件复位行为，也会在没有证据时猜测地址、寄存器或启动文件细节。

ST 的 STM32F7 编程手册和参考手册用于核对本课所需的复位入口、异常入口与应用入口边界。[1][2] 这些资料覆盖 F7 工程和处理器实现背景；本课只提取可迁移的控制流模型，不把 F7 的具体布局或实现细节推广到所有芯片。

3. 必要前置知识
#

你需要已经完成：最小 C 程序、固定宽度整数、指针、const/volatile、存储期、链接属性、编译器、构建和静态分析。这里不假定你知道异常模型、向量表格式、启动文件、链接脚本、ELF、栈、堆、寄存器、HAL/LL API 或任何开发板信息。

4. 核心原理
#

4.1 复位序列是一个控制流边界
#

复位序列解决的是“处理器重新开始执行时，谁先获得控制权”。可以把它抽象为五个事件：

复位发生
  -> 处理器按规定方式取得入口
  -> 进入复位处理程序
  -> 完成必要初始化边界
  -> 转入应用入口

这不是一条由 main 自己发起的普通函数调用链。入口由处理器的启动约定提供，复位处理程序是目标工程实现的代码对象，应用入口是随后由该处理程序转入的应用代码。

4.2 每个对象由谁定义、持有和触发
#

机制	解决的问题	定义位置	谁持有/提供	谁触发	调用如何流动
规定入口	复位后从哪里开始	处理器架构和目标启动约定	处理器按架构读取并提供控制权	复位事件	复位 -> 规定入口
复位处理程序	把启动边界连接到应用	目标工程的启动实现（本课不展开文件形式）	程序映像包含该代码	处理器转入入口后执行	入口 -> 处理程序
必要初始化边界	让应用获得约定的执行前提	启动实现与运行环境约定	处理程序维护顺序	处理程序内部步骤	处理程序 -> 初始化边界
应用入口	开始应用自己的控制流	应用代码	应用代码和其静态对象	处理程序完成边界后转入	初始化边界 -> 应用入口

这里的“持有”表示谁负责保存或提供该对象，不表示动态内存所有权。本课没有动态内存，也没有依赖注入。

4.3 主机的 `main` 不是硬件复位入口
#

主机实验通常由 C 运行环境准备进程，然后调用 main。因此实验代码中看到的 main() 是测试驱动的显式调用或由主机运行环境发起的调用；它只能帮助我们观察一个抽象顺序，不能证明目标处理器真的经历了复位、取得入口或执行了某种地址布局。

5. 关键术语与直观模型
#

术语	中文解释和本课边界
复位（reset）	处理器重新进入规定启动状态的事件；本课不讨论电源、看门狗或外部引脚的具体复位来源。
复位序列（reset sequence）	从复位到应用入口的一组有先后关系的启动事件。
复位向量（reset vector）	与复位入口相关的架构约定；本课只把它作为“入口信息”的名称，不讲条目格式。
向量表（vector table）	处理器启动约定使用的入口信息集合；具体布局和地址属于后续课。
复位处理程序（reset handler）	复位后执行、负责启动边界并转入应用的代码。
C 运行时初始化（C runtime initialization）	让 C 应用开始执行前所需的一类初始化边界；本课不展开其具体步骤。
Host Fake（主机替身）	在普通主机上用显式函数调用模拟概念事件，不等于目标硬件仿真。

6. 从输入到结果的完整流程
#

本课 Host Fake 的输入是一个空事件日志和一次对 reset_handler() 的显式调用，结果是按顺序记录的三个事件：取得入口、经过初始化边界、进入应用入口。

实验驱动 main
  -> 显式调用 reset_handler()
  -> reset_handler 记录“取得入口”
  -> reset_handler 记录“初始化边界”
  -> reset_handler 调用 app_entry()
  -> app_entry 记录“应用入口”
  -> main 检查日志顺序

定义在哪里：事件编号、日志数组和三个函数都在本课单文件示例中定义。
谁持有：静态事件数组由示例程序持有；reset_handler 负责写入，main 负责检查。
谁注入/提供：实验驱动提供一次显式调用；它不是硬件注入，也不是运行时依赖注入。
调用流：main -> reset_handler -> app_entry -> main 的断言。

7. 嵌入式系统中的对应位置
#

在真实目标中，入口信息和复位处理程序位于处理器启动约定与工程启动实现的交界处。应用代码位于后续层。把“入口取得”和“应用使用”分开，能为后续的向量表、启动文件、链接脚本和存储器布局课程建立清晰边界。

本课不指定 F4、F7、H5 或 H7 的地址、寄存器、启动文件名、HAL/LL API、时钟树、引脚或外设实例。不同系列的细节必须回到对应芯片的参考手册和启动实现核对，不能从本课模型推断。

8. 主机实验与硬件迁移边界
#

Host Fake 能验证：代码是否按预期记录了抽象事件顺序，以及断言是否能在顺序改变时失败。它不能验证：真实复位、电源或看门狗路径、处理器如何读取入口信息、目标映像的存储器布局、交叉工具链、下载、运行或板上测量。

本次运行没有开发板、调试器、构建日志或测量记录。下面示例标记为“示例，待主机执行；迁移后待上板验证”，hardware_verified 必须保持 false。

9. 最小代码示例
#

这是一个 C11 子集的概念模型。它没有函数指针、动态内存、寄存器或具体硬件地址。reset_handler 和 app_entry 是示例中的代码对象；main 只是主机实验驱动。

#include <assert.h>
#include <stdint.h>

enum event_id {
    EVENT_ENTRY_OBTAINED = 1,
    EVENT_INIT_BOUNDARY = 2,
    EVENT_APP_ENTRY = 3
};

static uint32_t event_log[3];
static uint32_t event_count;

static void record_event(uint32_t event)
{
    if (event_count < 3U) {
        event_log[event_count] = event;
        event_count += 1U;
    }
}

static void app_entry(void)
{
    record_event(EVENT_APP_ENTRY);
}

static void reset_handler(void)
{
    record_event(EVENT_ENTRY_OBTAINED);
    record_event(EVENT_INIT_BOUNDARY);
    app_entry();
}

int main(void)
{
    reset_handler();

    assert(event_count == 3U);
    assert(event_log[0] == EVENT_ENTRY_OBTAINED);
    assert(event_log[1] == EVENT_INIT_BOUNDARY);
    assert(event_log[2] == EVENT_APP_ENTRY);
    return 0;
}

代码层次是：枚举、日志和函数属于单文件的教学示例层；静态数组由程序自身持有；main 显式触发 reset_handler，所以这里的顺序是逻辑验证，不是硬件启动证据。若把 record_event(EVENT_INIT_BOUNDARY) 与 app_entry() 调换，断言仍可能通过数量检查但顺序断言会失败；这说明实验能观察顺序，却不能观察处理器内部真实动作。

10. 常见错误
#

说“芯片复位后直接调用 main”，忽略了规定入口和复位处理程序。
把 Host Fake 中的 reset_handler() 显式调用写成“模拟了真实复位”。
在没有芯片手册和构建证据时填写 ROM/RAM 地址、入口地址、寄存器值或启动文件名。
把复位向量、向量表当成本课已经讲完的格式细节；本课只建立术语边界。
因为主机断言通过，就声称已交叉编译、下载、运行或上板。

11. 调试观察点
#

事件顺序：逐行查看 event_log，确认记录顺序，而不是只看最终返回值。
调用栈：在 app_entry 设置断点，观察主机调用栈为 main -> reset_handler -> app_entry；这只是主机函数栈。
边界注释：在调试笔记中单独写出“主机显式调用”和“目标复位触发”，避免混用。
失败注入：暂时调换两个 record_event 调用，确认断言能够发现顺序错误，再恢复示例。
证据分类：记录编译器输出或主机运行输出时，标注为 Host Fake 证据；不要把它放入硬件证据。

12. 实战实验
#

在新的实验目录保存上面的代码，例如 reset-sequence-fake.c。先不修改顺序，使用已安装的 C 编译器执行主机实验：

gcc -std=c11 -Wall -Wextra -Wpedantic .\reset-sequence-fake.c -o .\reset-sequence-fake.exe
if ($LASTEXITCODE -eq 0) {
    .\reset-sequence-fake.exe
    $LASTEXITCODE
}

记录编译器版本、完整命令、退出状态和源码散列。然后只调换初始化边界与应用入口两行，重新运行，确认顺序断言失败；恢复后再次运行。若没有编译器，只能完成纸面追踪，不得把未执行的命令写成已验证。

实验报告至少包含：

你认为每个事件由谁定义、谁持有、谁触发；
主机日志能证明什么，不能证明什么；
调换顺序时哪一条断言失败，以及你如何确认日志来自修改后的源码。

13. 自检题
#

为什么目标处理器复位后不能简单等同于主机直接调用 main？
本课模型中的“规定入口”由谁提供，reset_handler 由谁实现？
Host Fake 的显式 reset_handler() 调用为什么不是硬件复位？
日志数组由谁持有，谁向它写入事件，谁读取并检查？
本课哪些细节必须留到向量表、启动文件或链接脚本课程？

14. 面试题
#

问：请解释 MCU 复位后到应用代码开始执行的大致路径，并说明如何在没有开发板时验证它。

答题要点：先说明处理器按架构和目标启动约定取得入口，再进入复位处理程序，经过必要初始化边界后转入应用入口；主机只能用 Host Fake 记录抽象顺序，不能验证真实入口读取、存储器布局或板上执行。涉及具体地址、文件和寄存器时，应要求对应芯片一手资料和构建/测量证据。

15. 延伸思考
#

如果应用入口之前的初始化失败，复位处理程序应如何留下可观察证据？先列出证据需求，不设计具体寄存器方案。
为什么把入口取得、初始化边界和应用入口分成事件，有助于后续定位启动故障？
在下一课学习向量表时，哪些问题仍然不能由本课的 Host Fake 回答？

16. 本节总结
#

复位序列是从处理器复位到应用入口的固定控制流边界：处理器按规定方式取得入口，复位处理程序完成必要初始化边界，再转入应用。主机的 main 调用只是运行环境或实验驱动提供的入口，不能替代目标硬件行为。Host Fake 能验证抽象事件顺序，但没有开发板和记录时，不能声称已构建、下载、运行或上板。

17. 下一步
#

完成实验并用自己的话回答自检题后，再进入“向量表”主题。后续课程将核对入口信息的组织方式；本课生成本身不会提高掌握度，也不会修改 completed 或 mastery。

18. 参考资料
#

ST, STM32F7 Series programming manual，编程手册 PM0253；访问日期：2026-10-01。用于核对 Cortex-M7/STM32F7 的复位、向量表和异常入口背景。[1]
ST, STM32F76xxx and STM32F77xxx advanced Arm-based 32-bit MCUs reference manual，参考手册 RM0410；访问日期：2026-10-01。用于核对 STM32F7 目标工程的复位与启动背景；不据此推断其他系列的具体布局。[2]