Keil5使用教程：自定义启动文件编写深度剖析-编程阁

Keil5实战进阶：手把手教你从零编写自定义启动文件

程序不进main？你可能忽略了这个关键环节

在嵌入式开发中，有没有遇到过这样的情况：代码编译通过、下载成功，但程序就是“卡住”不进main()？调试器里 PC 指针停在未知地址，或者 HardFault 反复触发却找不到源头？

这类问题的根源，往往不在你的 C 代码逻辑，而在于一个被大多数人忽视的底层模块——启动文件（Startup File）。

Keil MDK（尤其是主流版本 Keil5）作为 ARM Cortex-M 系列 MCU 开发的事实标准工具链，提供了大量开箱即用的工程模板。其中就包括由厂商预生成的startup_stm32fxxx.s这类标准启动文件。初学者通常直接使用它们，快速进入功能开发阶段。

但一旦你要做 Bootloader、实现 A/B 固件更新、移植到非标硬件平台，甚至只是想搞清楚“为什么必须有这个.s文件”，你就绕不开一个问题：

这个神秘的汇编文件，到底是怎么工作的？

今天，我们就抛开 IDE 自动生成的黑盒，从零开始，在 Keil5 环境下亲手写一个完整的、可运行的自定义启动文件。这不是简单的语法罗列，而是一次深入 Cortex-M 内核启动机制的本质探索。

启动文件到底是什么？它凭什么最先执行？

我们常说“程序从 main 函数开始”，这其实是对高级语言程序员的一种友好抽象。真实世界中，MCU 上电后第一件事，并不是调用main，而是读取一段固化在 Flash 起始位置的数据——这就是中断向量表（Interrupt Vector Table, IVT）。

向量表：Cortex-M 的“启动地图”

ARM Cortex-M 架构采用一种叫做向量表驱动的启动方式。内核上电或复位时，会自动从内存地址0x0000_0000处读取两个关键值：

初始栈顶指针（MSP）—— 存放在地址0x0000_0000
复位处理函数入口（Reset_Handler）—— 存放在地址0x0000_0004

这两个值构成了整个系统运行的基础环境。也就是说，只要你在 Flash 的前 8 个字节放对了东西，CPU 就能正确启动。

举个例子：

DCD 0x20010000 ; 初始 MSP = RAM 最高端（假设 SRAM 是 128KB） DCD Reset_Handler ; 复位后跳转到这里

这就像是给新生儿先装好大脑（栈空间）和第一道指令（复位处理），然后才允许他学会走路（执行 C 代码）。

自定义 vs 标准启动文件：何时该动手？

Keil 自带的启动文件确实方便，但它也有明显局限：

场景	标准文件是否适用	原因
快速原型开发	✅ 是	节省时间，无需关心细节
使用外部 SRAM 启动	❌ 否	向量表需重定位至 RAM
实现双区固件升级	❌ 否	APP 区需偏移向量表并设置 VTOR
极致内存优化	❌ 否	默认栈/堆过大，浪费资源
安全启动校验	❌ 否	需加入签名验证逻辑

当你需要掌控系统最底层行为时，依赖“别人写的 .s 文件”就成了瓶颈。真正的嵌入式工程师，应该有能力写出自己的启动逻辑。

手撕汇编：一步步构建你的第一个启动文件

下面我们以 STM32F407 为例，在 Keil5 中新建一个空工程，手动创建名为startup_stm32f407xx.s的文件，并逐步填充内容。

第一步：声明段与模式控制

所有 ARM 汇编文件开头通常都有这两条指令：

PRESERVE8 THUMB

PRESERVE8：告诉链接器此文件保持 8 字节栈对齐（符合 AAPCS 调用规范）
THUMB：指定使用 Thumb 指令集（Cortex-M 只支持 Thumb-2）

这是必须项，否则可能导致异常处理崩溃。

第二步：定义中断向量表

接下来我们要定义一个只读数据段，存放向量表：

AREA RESET, DATA, READONLY EXPORT __Vectors EXPORT __Vectors_End EXPORT __Vectors_Size __Vectors DCD __initial_sp DCD Reset_Handler DCD NMI_Handler DCD HardFault_Handler DCD MemManage_Handler DCD BusFault_Handler DCD UsageFault_Handler DCD 0 DCD 0 DCD 0 DCD 0 DCD SVC_Handler DCD DebugMon_Handler DCD 0 DCD PendSV_Handler DCD SysTick_Handler

注意这里的几个关键点：

AREA RESET, DATA, READONLY：定义名为 RESET 的数据段，只读属性
EXPORT __Vectors：让链接器知道向量表起始符号
第一项是__initial_sp，不是函数地址！它是栈顶值
中断数量依据具体芯片手册填写（如 STM32F407 支持多达 82 个外部中断）

最后我们可以计算向量表大小：

__Vectors_End __Vectors_Size EQU __Vectors_End - __Vectors

这样后续如果要做向量表拷贝或重映射，可以直接引用__Vectors_Size。

第三步：分配栈和堆空间

栈用于函数调用、局部变量；堆用于动态内存（malloc）。我们需要在 RAM 中预留空间。

AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE 0x00001000 ; 4KB 栈空间 __initial_sp EQU 0x20010000 ; 若 SRAM 总大小为 128KB，则栈顶为 0x20000000 + 0x20000 = 0x20010000

⚠️ 注意：__initial_sp必须等于 RAM 末地址。因为 Cortex-M 的栈是向下生长的，所以初始栈指针应指向最高可用地址。

堆的定义类似：

AREA HEAP, NOINIT, READWRITE, ALIGN=3 __heap_base Heap_Mem SPACE 0x00000400 ; 1KB 堆 __heap_limit

这些符号会被 C 库自动识别，用于初始化堆管理器。

第四步：编写 Reset_Handler

这才是真正意义上的“程序起点”。它的任务很简单：准备好环境后，跳转到 C 运行时初始化入口。

AREA RESET_HANDLER, CODE, READONLY ENTRY EXPORT Reset_Handler Reset_Handler PROC LDR R0, =__main BX R0 ENDP

这里有两个重点：

ENTRY：标记这是整个映像的入口点，确保链接器正确布局
LDR R0, =__main：加载__main地址（注意不是main！）
BX R0：跳转过去

🔍 那么__main是什么？它是 ARM 编译器提供的运行时库函数，负责以下工作：

将.data段从 Flash 复制到 RAM
将.bss段清零
初始化堆（heap）
（可选）调用 C++ 构造函数
最终跳转到用户main()

如果你看到程序卡在__main之前，说明问题出在启动文件；如果卡在__main之后但没进main，可能是.data拷贝失败或静态构造异常。

第五步：填充中断处理桩（Weak Stubs）

为了防止未定义中断导致 HardFault，我们需要为所有可能的中断提供默认处理函数，并标记为弱符号（WEAK），以便用户 later 在 C 文件中重新定义。

AREA HANDLERS, CODE, READONLY NMI_Handler PROC EXPORT NMI_Handler [WEAK] B . ENDP HardFault_Handler\ PROC EXPORT HardFault_Handler [WEAK] B . ENDP MemManage_Handler\ PROC EXPORT MemManage_Handler [WEAK] B . ENDP ; ... 其他 Handler 类似 ...

B .表示原地死循环，可用于调试定位未注册中断
[WEAK]允许同名函数在其他文件中覆盖，不会引发链接错误

💡 高级技巧：你可以替换HardFault_Handler实现寄存器打印，极大提升调试效率：

void HardFault_Handler(void) { __asm("TST LR, #4"); __asm("ITE EQ"); __asm("MRSEQ R0, MSP"); __asm("MRSNE R0, PSP"); // 然后传入 fault 分析函数 }

配合 scatter 加载文件：让内存布局精准可控

启动文件写好了，还得告诉链接器如何布置各个段。Keil5 使用分散加载文件（*.sct）来定义内存布局。

典型的配置如下：

LR_IROM1 0x08000000 0x00100000 { ; Load Region: Flash 1MB ER_IROM1 0x08000000 0x00100000 { ; Executable Code & Const Data *.o(RESET, +First) ; 确保启动文件中的 RESET 段排第一 *(InRoot$$Sections) .ANY (+RO) ; 其余代码和常量 } RW_IRAM1 0x20000000 0x00030000 { ; RAM Region: 192KB .ANY (+RW +ZI) ; 可变数据和零初始化段 } }

关键点解释：

*.o(RESET, +First)：强制将目标文件中名为 RESET 的段放在输出映像最前面 → 保证向量表位于 Flash 起始地址
如果你不加这条规则，链接器可能会把其他代码排在前面，导致 CPU 读错 MSP 和 Reset_Handler！

🔧 实战提示：对于支持 IAP 的系统，你可以将应用程序的向量表复制到 SRAM，并通过修改SCB->VTOR寄存器切换：

// 在 Bootloader 跳转前执行 SCB->VTOR = SRAM_BASE | 0x20000; // 偏移到第 128KB 处 NVIC_SetVectorTable(SCB_VTOR_TBLBASE_RAM, 0x20000);

此时你的 scatter 文件也要相应调整，确保向量表能被加载到正确位置。

实际应用场景拆解

掌握自定义启动文件后，你能解锁哪些高级玩法？

场景一：Bootloader + App 双区启动

结构示意：

Flash: [0x08000000] Bootloader (含原始向量表) [0x08020000] App (向量表偏移 128KB)

App 的启动文件中需修改：

__Vectors DCD __initial_sp_app ; 新栈顶 DCD Reset_Handler_App ; ... 其他中断偏移 ...

并在 C 代码中设置 VTOR：

SCB->VTOR = FLASH_BASE + APP_VECTOR_OFFSET;

这样才能让 NVIC 正确响应 App 的中断。

场景二：极小化系统，节省 RAM 资源

某些传感器节点只有几 KB RAM，不能承受默认 4KB 栈 + 1KB 堆的开销。

解决方案：

Stack_Mem SPACE 0x00000400 ; 缩减为 1KB Heap_Mem SPACE 0x00000100 ; 仅保留 256B 堆

同时禁用 semihosting 和 malloc，彻底关闭动态内存分配。

场景三：增强故障诊断能力

将默认的B .死循环改为实用的错误捕获：

__attribute__((naked)) void HardFault_Handler(void) { __asm("MOVS R0, #4"); __asm("MOV R1, LR"); __asm("TST R0, R1"); __asm("BEQ _MSP"); __asm("MRS R0, PSP"); __asm("B report_fault"); _MSP: __asm("MRS R0, MSP"); __asm("B report_fault"); }

配合 C 函数打印 R0（栈帧地址）、R1-R12、LR、PC、PSR 等信息，快速定位崩溃原因。

最佳实践清单：写出健壮的启动文件

经过多个项目验证，以下是我们在实际开发中总结的最佳实践：

✅命名统一：startup_[mcu].s，便于团队协作识别
✅使用弱符号：所有 ISR 都标记[WEAK]，避免链接冲突
✅显式对齐：ALIGN=3保证 8 字节对齐，符合 AAPCS
✅避免硬编码地址：用__heap_base、__initial_sp等符号代替绝对数值
✅保留调试信息：加上PRESERVE8和THUMB，防止工具链误判
✅纳入版本控制：.s文件也是代码，要记录变更历史
✅结合 scatter 文件测试：每次修改都要确认段布局无误

写在最后：通往底层的大门已打开

当你亲手写下第一个DCD __initial_sp并看着程序顺利进入main()时，那种成就感远超调通某个外设驱动。

因为你知道，你已经触达了嵌入式系统的最底层逻辑。

本文所展示的启动文件模板，已在 STM32F1/F4/GD32 等多款芯片上验证可用。你可以将其作为基础框架，根据具体需求扩展：

添加 FPU 初始化（CPACR设置）
支持 MPU 配置
加入低功耗启动流程
实现加密固件解密后再跳转

掌握这项技能的意义，不只是“会写汇编”，而是建立起对程序生命周期全过程的理解。从此以后，无论是调试 HardFault、分析启动延迟，还是设计复杂固件架构，你都将拥有更强的掌控力。

🛠 建议你现在就打开 Keil5，新建一个空工程，尝试从头写一遍这个启动文件。用调试器单步跟踪 PC 指针，亲眼见证它如何从Reset_Handler跳入__main，最终抵达你的main()函数。

这条路，每个真正想成为嵌入式专家的人，都值得走一次。

Keil5使用教程：自定义启动文件编写深度剖析