M4内核启动全过程（从零写代码，不用任何库，深入分析启动过程和函数调用规则）

引言

玩过stm32的小伙伴，应该知道，在使用的keil工程里面有一个start.s的启动文件（网上关于这个启动文件的分析很多，本文不是讲解启动文件的文字，不打算具体讲解这个文件的内容）。start.s文件是芯片复位、启动要运行的一个代码文件（其实在之前还会运行其它的东西，在后面会介绍下），在复位中断里面会执行SystemInit初始化系统时钟，最后调用__main（keil C库的API），__main调用我们写的main函数，进入用户写的代码。同时在讲解的过程中，对函数调用的规则进行深入分析，C和汇编的调用规则进行理论和实践的讲解。

本文将对上述过程进行分析，从芯片刚上电的时刻开始，芯片进行了哪些工作，最终启动完成，运行main，该部分的代码全部有博主手写，并未使用任何C库中的代码，希望读者对芯片的启动过程有一个更详细的了解，而非仅仅知道start.s文件中的那些内容。

博主用的芯片是stm32F407(下面简称F4芯片、芯片等)，启动地址（内部flash地址）在0x0800 0000，RAM在0x2000 0000位置，flash大小512KB，RAM 192KB（分为128KB+64KB，下文中为了省事，直接将这两个RAM放到一起了，不影响结论，且结论和RAM大小无关）。

注：下文中的flash大小和ram大小可能会出现错误，这是因为博主写的时候，用了两个芯片做实验，flash、ram的起始地址和大小是不影响本文的结论。

一、芯片启动过程

1.1 内存映射

图1 部分内存映射

在F4芯片中的部分内存映射如图1所示。在芯片刚上电的时候，PC指针实际的值是0x0000_0000，并非很多人理解的0x0800_0000（boot0为低电平），其执行的是Boot ROM中的代码，这部分代码是芯片厂商烧录进去，用户无法更改。在这部分代码中，芯片厂商可以在里面做一些定制性的操作。例如同样的芯片，配置不同（关掉某些功能），成为两个芯片，其也会去检测boot0、boot1引脚，在stm32中，若是boot0为0（低电平）、boot1任意电平，pc会赋值为0x0800_0000，执行内部的flash（若是boot1、boot1为1，执行SRAM中的程序）。在Boot ROM中，芯片厂商会进行一些定制的操作，具体与本文内容无关。在F4芯片中，boot为0（低电平）、boot1任意电平时，会跳转到0x0800_0000处，开始执行用户写的代码。

在之前的文章中（keil下载程序具体过程），博主说明了一个keil编译生成的axf文件，是如何从在keil中点击download按钮之后下载到内部的flash中。感兴趣的看看博主的文章，在flash中的储存的是bin文件，我们先看下bin文件有什么。

1.2 bin文件

bin文件是由axf文件转化过来的，axf文件ELF格式的二进制文件，里面除了包含bin文件的内容，还包含了调试信息、地址信息等。keil编译之后，产生的链接结果，博主设置了在编译之后生成bin文件。

图2 keil编译结果

我们看下bin文件的大小。

图3 bin文件大小

bin文件大小2780字节。由图2可知:

Code=2436 RO-data=340 RW-data=4 ZI-data=276。

一个bin文件包含Code、RO、RW、ZI段的信息，keil工程中，代码部分放在Code中，只读数据放到RO中（如常量字符串、const修饰的变量等等），可读数据放到RW中（如已经初始化的全局变量），ZI段放的是未初始化的全局变量等定义了的变量，但未初始化，这样可以减少bin文件的大小。

Code + RO + RW = 2436 + 340 + 4 = 2780 = bin文件大小，没有ZI段，ZI段只需要记录起始地址和长度，将该部分内存全部清零即可，故可知，bin的文件内容实际就是Code、RO、RW三部分。

至于Code、RO、RW具体应该如何存放，放到哪个地址，需要看分散加载文件如何写。

关于映像文件的介绍先到这里，只是简单的说了下映像文件，后面会出一篇文章专门介绍映像文件的组成。

1.3 分散加载文件

分散加载文件（sct后缀的文件）是一个文本文件，通过编写一个分散加载文件来指定ARM连接器在生成映像文件时如何分配RO/RW/ZI等数据的存放地址，HTQ_MCU芯片的分散加载文件如下所示。

LR_IROM1 0x08000000 0x00100000  {    ; load region size_region
  ER_IROM1 0x08000000 0x00100000  {  ; load address = execution address
   *.o (RESET, +First)
   *(InRoot$$Sections)
   .ANY (+RO)
   .ANY (+XO)
  }
  RW_IRAM1 0x20000000 0x00020000  {  ; RW data
   .ANY (+RW +ZI)
  }
}

分散加载文件的区域分两类：

加载区：该映像文件开始运行前存放的区域，即当系统启动或加载时应用程序存放的区域（本文的Flash部分）。
执行区：映像文件运行时的区域，即系统启动后，应用程序进行执行和数据访问的存储器区域，系统在实时运行是可以有一个或多个执行块（本文也是指Flash部分）。

上述分散链接文件定义了一个区域ER_IROM1（起始地址为0x08000000，大小为0x00100000，为内部的Flash映射地址），在ER_IROM1中存放bin，也在这个上面执行。有的时候，存放的bin位置和执行地址，二者可能不一致，需要修改分散链接文件。定义了区域RW_IRAM1，起始地址为0x20000000，大小0x00020000 ，为SRAM映射地址。

在分散链接文件中，只有RO、RW属性，并没有Code属性。其实，在分散链接文件看来，Code本身也是一种RO数据，因此，

Code=2436 RO-data=340 RW-data=4 ZI-data=276。

Code和RO在bin中放到一起，叫做RO段，RW放到RW段。

由上述可知，我们的bin存放在0x08000000处，该处存放的是RO段（Code部分和RO部分），紧接着存放的是RW段，这一点，我们在后面可以得到验证。

1.4 链接符号

在keil中，我们可以使用类似于下面这样的链接符号，在代码中获得分散链接文件中定义的区域相关信息，还可以更具体的获得RO段、RW段、ZI段的信息。在本文中，我们使用如下链接符号获得bin中的信息。

extern int Image$$ER_IROM1$$Base;       //RO段的起始地址
extern int Image$$ER_IROM1$$Limit;      //RO段的结束地址

extern int Image$$RW_IRAM1$$RW$$Base;   //RW段的起始地址，加载地址
extern int Image$$RW_IRAM1$$RW$$Limit;  //RW段的结束地址，加载地址

extern int Load$$RW_IRAM1$$RW$$Base;    //RW段的起始地址，执行地址
extern int Load$$RW_IRAM1$$RW$$Limit;   //RW段的结束地址，执行地址

extern int Image$$RW_IRAM1$$ZI$$Base;   //ZI段的起始地址，执行地址
extern int Image$$RW_IRAM1$$ZI$$Limit;  //ZI段的结束地址，执行地址

RO段的数据，并不需要改动，因此存放在0x0800 0000处不动。RW段数据需要从加载地址拷贝到执行地址处运行，ZI段都是零，因此，只需要知道执行地址即可（bin中也没有ZI段，只有ZI段的起始地址和结束地址信息）。

1.5 start.s文件简述

在stm32f407中，使用的是startup_stm32f40_41xxx.s作为启动文件。下面的代码做了简化。

Stack_Size      EQU     0x00001000

                AREA    STACK, NOINIT, READWRITE, ALIGN=3
Stack_Mem       SPACE   Stack_Size
__initial_sp

Heap_Size       EQU     0x00000200

                AREA    HEAP, NOINIT, READWRITE, ALIGN=3
__heap_base
Heap_Mem        SPACE   Heap_Size
__heap_limit

                PRESERVE8
                THUMB

; Vector Table Mapped to Address 0 at Reset
                AREA    RESET, DATA, READONLY
                EXPORT  __Vectors
                EXPORT  __Vectors_End
                EXPORT  __Vectors_Size
__Vectors       DCD     __initial_sp               ; Top of Stack
                DCD     Reset_Handler              ; Reset Handler
                DCD     NMI_Handler                ; NMI Handler
                DCD     HardFault_Handler          ; Hard Fault Handler
                DCD     MemManage_Handler          ; MPU Fault Handler
                DCD     BusFault_Handler           ; Bus Fault Handler
                DCD     UsageFault_Handler         ; Usage Fault Handler
                DCD     0                          ; Reserved
            ......
__Vectors_End

__Vectors_Size  EQU  __Vectors_End - __Vectors

                AREA    |.text|, CODE, READONLY

; Reset handler
Reset_Handler    PROC
                 EXPORT  Reset_Handler             [WEAK]
        IMPORT  SystemInit
        IMPORT  __main

                 LDR     R0, =SystemInit
                 BLX     R0
                 LDR     R0, =__main
                 BX      R0
                 ENDP

最开始，设置了栈、堆的大小，之后是中断向量表，这部分代码存放在bin文件的最开头，bin的前两个字就是stack和pc的值，对应的就是__initial_sp、Reset_Handler。我们的代码就进入到了Reset_Handler即复位中断，在这里面，调用SystemInit初始化系统的时钟，调用__main，完成一些环境的初始化（后面具体展开），最后进入main（应用程序的入口）函数，即我们写的代码，控制权来到了程序员手中。

打开汇编代码的时候，我们可以看到如下的代码。

LDR R0, =__main，之后会跳转到这里

这里会多出来__scatterload、__rt_entry函数，这些都是C库里面的函数，进行一些初始化的工作。

截取了一些代码放这里。有兴趣的自己看下里面的汇编代码具体这么做的，这里总结下里面做的内容。

__scatterload：将RORW段从加载域复制到运行域，并完成ZI段初始化。

__rt_entry：完成库函数的初始化工作，如果采用分散装载技术，还必须实现__user_initial_stackheap函数，重新定义堆栈和堆空间，最后自动跳转向main()函数。

在__rt_entry函数里面，使用__rt_lib_init完成库的初始化工作，调用__rt_stackheap_init()设置stack和heap，最后进入main函数。main函数的返回值由__rt_exit函数处理。

__main是C/C++应用程序的入口点，main是用户应用程序入口点。简单的总结下__main函数做了哪些工作：

1、将非固定(nonroot)的执行代码域(region)从加载地址空间搬运到运行地址空间

2、将ZI域清零

3、跳转到__rt_entry()

__rt_entry函数做的工作：

1、调用__rt_stackheap_init()简历数据栈和数据堆

2、调用__rt_lib_init()初始化应用程序用到的C运行时库

3、调用main函数，main是用户程序的入口点，在main函数中，可以调用C运行时库的相应函数

4、调用exit()函数，退出应用程序

既然想用全部手写代码实现启动代码的过程，我们在上面的start.s的基础上，将__main函数改成我们自己的代码就可以完成。__main函数主要完成3个功能。__rt_entry中的初始化C库的部分，由于我们未用到C库，可以去掉，只保留初始化堆栈和进入main的功能。__scatterload部分我们手动实现它。

二、实现__main函数

在实现__main的时候，博主将其功能分为如下几类：

1、初始化RW：将RW段由加载域搬运到运行域。由于RO段是不动的，因此，RO段搬运的代码未实现。

2、初始化ZI：ZI段都是0，因此，只是将某一块内容清空即可。

3、跳转main：考虑汇编的难读性，博主实现的代码均是使用C完成，因此，在start.s中直接跳转到main.s了。

画个简图表示上面实现的关系。

2.1 加载域和运行域的关系

添加一张ARM给的图

图片来源于《Introductiontothe Armv8-M Architecture and its ProgrammersModel》

在1.3中已经说明了加载域和运行域是什么含义，下面用图表示下二者中的具体含义。

左边是flash部分，从0x0800 0000地址开始，bin文件里面内容摆放的位置，从低地址开始，分别是RO、RW、ZI段的信息，code存放的位置也是RO段，RO段不需要动。RW段的内容，需要从flash搬运到sram中，在flash和sram中存放的起始地址、结束地址如下：

flash：Image$$RW_IRAM1$$RW$$Base   -----    Image$$RW_IRAM1$$RW$$Limit
sram:   Load$$RW_IRAM1$$RW$$Base    -----    Load$$RW_IRAM1$$RW$$Limit

上面的链接符合在1.4节有说明。

2.2 RW段拷贝

既然知道了RW段的存放位置和目的地址，因此，只需要写一个简单的函数将里面的内容全部copy到sram即可。函数如下：

void rw_section_init(uint32_t src_addr, uint32_t dst_addr, uint32_t length)
{
    uint32_t * psrc, *pdst, *pend;
    
    psrc = (uint32_t*)src_addr;
    pdst = (uint32_t*)dst_addr;
    pend = (uint32_t*)(src_addr + length);
    
    while(psrc < pend){
        *pdst++ = *psrc++;
    }
}

函数很简单，src_addr表示起始地址，为flash中bin文件的RW段起始地址，dst_addr表示目的地址，为sram中的RW段起始地址，length表示copy字节长度。具体的值为2.1小节的flash起始地址和sram的起始地址。

2.3 ZI段清零

ZI段的内容在flash中只保留了起始地址，长度等信息，并无实际内容，在sram直接清空即可。这里说一下，在实际代码中，当一个变量小于8 Byte时，哪怕未赋值，实际存放的也是RW段，而非ZI段。读者可以自行试试。

ZI段初始化代码很简单。

void zi_section_init(uint32_t src_addr, uint32_t length)
{
    uint8_t * psrc, *pend;
    
    psrc = (uint8_t*)src_addr;
    pend = (uint8_t*)(src_addr + length - 16); 
    while(psrc < pend){
        *psrc++ = 0;
    }
}

src_addr的值为Image**RW_IRAM1**ZI**Base，length为（Image**RW_IRAM1**ZI**Limit - Image**RW_IRAM1**ZI**Base）。注：*表示的是$，CSDN上两个$显示的有问题。

这里解释下为什么这行代码里面有一个 “ - 16 ”的操作：

pend = (uint8_t*)(src_addr + length - 16)

我们都知道ZI段里面的值都是0，包含所有未初始化的变量、数组、堆、栈等等。在博主写的代码里，堆的内存大小设置为0（为了简化代码），栈的大小设置为200 Byte（大小无所谓），ZI段一共276 Byte。用一个图来表示ZI段的内容。

在sram中的ZI段大概类似于上图所示。在我们的代码里面，应该将从ZI**Base开始到ZI**Limit中的所有数据都清空，设置为0。但博主在写的时候，用的纯C，使用C就必须设置好sp指针，sp指针设置的位置为ZI**Limit。在执行LDR R0, =main（在start.s中）时，sp指针会向下移动4B，在main和zi_section_init中又定义了一些局部变量，因此又要去掉一些空间。因此必须给留出一些空间。接下来的分析将和编译器有关，因此，若是对该部分不是很熟悉的小伙伴，看看即可。

三、ATPCS

3.1 ATPCS

在解释之前，先补充点额外的知识，与ARM链接器相关，ATPCS相关知识。ATPCS是ARM程序和Thumb程序中子程序调用的基本规则（博主发的文章里面有讲解ATPCS）。在ATPCS中有如下两条规则：

1、子程序间通过R0--R3传递参数，被调用的子程序在返回前无需恢复寄存器R0--R3的内容。

2、在子程序中，使用R4--R11保存局部变量，如果在子程序中使用到了寄存器R4--R11中的某些寄存器，子程序进入前需要保存这些寄存器的值，在返回时需要恢复。未用到，不处理。在Thumb程序中，通常只能使用寄存器R4--R7来保存局部变量。

ATPCS部分，博主会抽时间写一篇文章专门讲解ATPCS规则（纯理论的文章，估计很多人不太喜欢看^_^）本小节的内容可以看作ATPCS规则的实战部分讲解了。

keil编译出来的各个段大小，RO段=Code+RO-data，RW段=RW-data，ZI段=ZI-data=276=0x114Byte。

Program Size: Code=2508 RO-data=340 RW-data=4 ZI-data=276

3.2 函数调用详细分析

在start.s中还未进main函数时，芯片的现场环境如下：

从这里可以看出一些信息：

1）博主在进入main之前设置RO--R11分别为0--11，为了后面调试追踪寄存器入栈。

2）栈顶指针为0x118，而我们设置的ZI段为0x114，这是因为sp指针指向栈最后一个单元的后一个单元，即如图所示：

故sp的值为0x118 = 0x114 + 4。接下来进入main函数。

先上main的代码（无用的代码已删去）

int main()
{
    uint32_t image_rw_start_addr = (uint32_t)&Image$$RW_IRAM1$$RW$$Base; 
    uint32_t image_rw_length = (uint32_t)&Image$$RW_IRAM1$$RW$$Limit - (uint32_t)&Image$$RW_IRAM1$$RW$$Base; 
    
    uint32_t load_rw_start_addr = (uint32_t)&Load$$RW_IRAM1$$RW$$Base; 

    uint32_t image_zi_start_addr = (uint32_t)&Image$$RW_IRAM1$$ZI$$Base; 
    uint32_t image_zi_length = (uint32_t)&Image$$RW_IRAM1$$ZI$$Limit - (uint32_t)&Image$$RW_IRAM1$$ZI$$Base;  

    rw_section_init(load_rw_start_addr, image_rw_start_addr, image_rw_length);

    zi_section_init(image_zi_start_addr, image_zi_length);
}

首先，结合zi_section_init函数，先计算下main和zi_section_init函数一共有多少局部变量：

main:5个，分别是image_rw_start_addr、image_rw_length、load_rw_start_addr、image_zi_start_addr、image_zi_length

zi_section_init：2个，分别是psrc、pend

刚进入main的时候

栈指针为0x118。

进入rw_section_init函数之前，寄存器的值和监视的变量。

栈大小为0x110，PC为0x10000A1A。

再看看各个变量的值以及寄存器里面的值

具体的就不分析了，可以自己对照上面红色方框里面的值，说下结论：Watch 1里面监视变量在R8、R9、R10、R4、R6中储存，其余未用到的寄存器都是保存的开始设置的值，如R5保存的值为5，R7为7。

进入rw_section_init函数之后

进入函数之后，栈值为0x110。R0--R2保存的是rw_section_init，和load_rw_start_addr, image_rw_start_addr, image_rw_length值相等（肯定的）。这一步是传递参数，使用LR保存PC寄存器的值，但LR的值为0x0x10000A25，不是0x10000A1A。

重新来看下，在进入函数之前的rw_section_init汇编代码，可以看到，红框部分有四条汇编代码，故LR的值应该为0x0x10000A20+4，至于为0x0x10000A25而非A24，这是因为在ARMv7之前，指令集分为ARM和Thumb，而进入到Cortext-M3之后，使用的是Thumb2，不再区分ARM和Thumb状态，但依然保留某些时候会将PC的最低为置1（具体什么时候博主也忘了，在《Cortex-M3权威指南》中博主曾经看到过一眼，具体在哪里就不太清楚了）。

刚进入rw_section_init函数，sp还未变动，只是R0--R2变化。

再运行一步，看看栈是如何变化的。

栈减少了0x10 B，说明入栈了4个字（word）。看看栈的变化，再四个红色框框里面，0x2000 00FC地址是不不变化的，但后面四个字就变成了0x2000 0004、0x0000 0005、

0x0000 0114、0x1000 0A25。 0x1000 0A25是PC的值，最先入栈（栈是倒着增长），依次入栈 0x0000 0114、 0x0000 0005、0x2000 0004。这三个是寄存器R6、R5、R4的值（如此看来寄存器应该是高寄存器先入栈），按照ATPCS规则，R4--R11是可以保存局部变量的，而rw_section_init函数刚好三个局部变量，看看汇编代码。

确实跟分析的一样。接下来就是将R0保存到R3，R0、R4、R5分别保存psrc, pdst, pend的值（准确的说，在C中的局部变量psrc, pdst, pend实际就是R0、R4、R5）。

看看具体的汇编代码。

对照着C的循环代码。

可以看到，R6实际上是赋值数据的中间变量作用。最后弹出提前保存的R4--R6、LR

直接将lr的值弹出到pc中，完成pc的赋值。

函数调用的具体过程、栈的变化、寄存器和变量的分配使用等在这里进行了较深入的介绍。这里虽然没有直接解释为什么“- 16”，但进行了间接的解释，相信不难理解，进入到zi_section_init函数时，要对栈的内容进行保护（“- 16”的操作）。具体的不分析了，这个函数比较简单，简单的看下即可。

这里栈为0x20000108，最开始栈为0x0x20000118，相差0x10即16B，符合前面的操作。

四、题外话

关于__main函数的分析，暂时就到这里了。里面有很多内容可以深挖下去，以后若是继续进行研究再来补充。博主在写代码时，执行zi_section_init函数之前的内容完全没问题，就是执行zi_section_init函数时，程序老是跑飞，到HardFault_Handler里面。一开始百思不得其解，但我将pend的值设置的小一些（上面“-16”的操作部分），发现程序可以正常运行完成了。16这个值最开始是博主试验出来的（^_^），后面根据ATPCS规则，想通了这部分的代码为啥是16了（当然，不排除想错了的可能.....）。

总结一下芯片的启动过程：