2. LiteOS-M内核启动流程深度解析：从上电到main函数的完整链路

大家好，我是你们的讲师。今天我们来聊聊LiteOS-M内核的启动流程。很多初学者拿到开发板，按下复位键，看着串口打印出“Hello World”，觉得一切理所当然。但中间发生了什么？CPU从上电到执行你的main函数，到底走了多远的路？

我个人习惯把启动流程比作一场接力赛。第一棒是硬件复位逻辑，第二棒是汇编启动文件，第三棒是C语言初始化，最后才交到你的main函数手里。每一棒都不能掉链子，否则系统跑不起来。

2.1 从上电到复位向量：第一行代码在哪里？

芯片上电后，CPU会从一个固定的地址读取第一条指令。这个地址，就是复位向量。对于Cortex-M系列内核，复位向量位于向量表的第二个位置（偏移0x0004）。向量表的第一个位置存放的是栈顶指针。

嗯，这里要注意：CPU不是直接跳转到main函数的。它先要建立基本的运行环境。我见过不少新手，在链接脚本里把main函数的地址直接写到了复位向量，结果系统一启动就崩溃。为什么？因为栈还没准备好，全局变量还没初始化，你让main函数怎么活？

正确的流程是这样的：

1. CPU从0x00000000加载栈顶指针到SP寄存器
2. 从0x00000004加载复位向量地址到PC寄存器
3. 跳转到复位向量指向的代码（通常是Reset_Handler）

说白了，前两步是硬件自动完成的，第三步才开始执行我们的软件。

2.2 汇编启动文件分析：Reset_Handler做了什么？

Reset_Handler是启动流程的“总指挥”。它通常写在汇编文件里，比如LiteOS-M的startup.s。我刚开始做鸿蒙适配时，第一次打开这个文件，满屏的汇编指令看得我头皮发麻。但后来我总结了一下，它其实就干了三件事：

你想想看，如果BSS段没清零，你的全局变量初始值可能是随机的。我曾经在一个项目中遇到过这样的bug：一个全局标志位默认应该是0，结果上电后是0x55，导致状态机直接跑飞。查了两天才发现是启动文件里忘了调用BSS清零函数。

下面是LiteOS-M启动文件的核心片段，我加了注释：

Reset_Handler PROC
    EXPORT  Reset_Handler
    IMPORT  __main
    IMPORT  SystemInit

    ; 第一步：设置栈指针
    LDR     R0, =__stack_top
    MOV     SP, R0

    ; 第二步：调用系统初始化（时钟、外设等）
    BL      SystemInit

    ; 第三步：跳转到C库的__main，完成BSS/数据段初始化
    B       __main
    ENDP

注意这里的__main不是你的main函数。它是C运行时库的入口，负责完成BSS清零、数据段拷贝、构造函数调用等脏活累活，最后才调用你的main()。

2.3 系统时钟与中断向量表配置

系统时钟配置，是启动流程中容易被忽视的一环。很多芯片默认使用内部低速RC振荡器，频率只有几兆赫兹。如果你不配置PLL，系统跑得比乌龟还慢。

LiteOS-M的时钟配置通常在SystemInit()函数里完成。这个函数在跳转到__main之前被调用。我建议你在这个函数里至少做以下几件事：

• 切换时钟源： 从内部RC切换到外部晶振，再通过PLL倍频到目标频率
• 配置Flash等待周期： 频率越高，Flash读取需要插入的等待周期越多，否则会跑飞
• 使能外设时钟： 至少把GPIO、UART等基础外设的时钟打开

中断向量表呢？它是一张表格，存放着每个中断对应的处理函数地址。Cortex-M内核要求向量表必须按顺序排列，从0地址开始。LiteOS-M的向量表通常定义在汇编文件或C文件中，像这样：

__Vectors DCD     __stack_top          ; 栈顶指针
         DCD     Reset_Handler        ; 复位向量
         DCD     NMI_Handler          ; NMI中断
         DCD     HardFault_Handler    ; 硬错误中断
         ; ... 其他中断向量 ...

嗯，这里有个坑：如果你在运行时动态修改了中断向量表（比如实现IAP升级），一定要确保新向量表在RAM中且地址对齐。我曾经遇到过向量表地址没对齐，导致中断跳转到了错误的位置，系统直接HardFault。

2.4 内存布局与链接脚本解读

链接脚本（.ld文件）决定了你的代码和数据在内存里怎么摆放。LiteOS-M的链接脚本通常包含以下几个关键区域：

我刚开始看链接脚本时，最困惑的是.data段为什么有两个地址——一个在Flash，一个在RAM。后来才明白：全局变量的初始值必须保存在Flash里（掉电不丢失），但运行时必须搬到RAM里（Flash读取速度慢，且不能写）。启动文件里的数据段拷贝，干的就是这个活。

下面是一个简化的LiteOS-M链接脚本片段：

MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .text : {
        *(.vectors)
        *(.text*)
        *(.rodata*)
    } > FLASH

    .data : {
        _sdata = .;
        *(.data*)
        _edata = .;
    } > RAM AT > FLASH

    .bss : {
        _sbss = .;
        *(.bss*)
        _ebss = .;
    } > RAM
}

注意.data段的AT > FLASH，它告诉链接器：这个段的加载地址在Flash，但运行地址在RAM。启动文件需要把数据从Flash拷贝到RAM。

2.5 启动流程全景图

说了这么多，我们来画一张图，把整个启动流程串起来。这张图我每次培训都会画，因为它能帮你建立全局视角。

这张图里，我特别标出了两个关键分岔点：SystemInit和__main。前者负责硬件层面的初始化，后者负责软件运行环境的准备。两者缺一不可。

2.6 常见启动故障与定位方法

最后，我分享几个我在项目中遇到过的启动故障案例，希望能帮你少走弯路。