cortex-m3启动代码详解

1.1 启动代码内容

1)  硬件初始化:最起码的是要初始化堆栈指针。

2) C语言环境 :在main函数调用之前要完成对一些变量的初始化。

3)  应用初始化:  这主要取决于你的应用。比如设置系统的晶振、时钟。

1.2 图解M3启动过程

1）程序开始运行，系统启动代码首先要完成硬件初始化，比如说对堆栈的初始化。图中显示初始化堆栈指针为之前

预先定义好堆栈区域的末尾(M3内核堆栈时向下生长)。

2）初始化变量初始值为0全局变量和静态变量

3)初始化变量初始值为非0的变量，链接器将存储在ROM的初始值复制到相应的RAM中。

4)初始化应用（可选）

5）最后调用主函数

6）附录

关于C语言中变量的存储区域。

1、初始化和非初始化的变量都存放在内存区(RAM);

2、全局const被存放在代码区。

3、static存放在内存区（RAM)

4、对于数量少的局部变量一般是寄存器操作

5、对于数据量大的局部变量则采用是堆栈操作。

1.3 M3启动代码实例分析

下面例子为在iar下，由EFM32芯片(M3内核)厂商提供的启动代码startup_efm32g.s。IDE为IAR FORARM 6.0。其中

ROM(0x00000000-(0x20000000-1));

RAM(0X20000000-(0X20000000+0X00004000-1))

首先，上电后程序从向量表中取出复位异常ISR地址，跳转至异常服务程序Reset_Handler,程序如下：

[cpp] view plain copy print?

1. PUBWEAK Reset_Handler  

2.         SECTION .text:CODE:REORDER(2)  

3. Reset_Handler  

4.         LDR     R0, =SystemInit  

5.         BLX     R0  

6.    

7.         LDR     R0, =__iar_program_start  

8.         BX      R0  

其中Reset_Handler为PUBWEAK，即可以被我们重写的同名函数覆盖。一般来说，我们可以直接使用EFM32提供的Reset_Handler。可以看到在startup_efm32.s中Reset_Handler只是调用了两个函数。通过单步调试，进入SystemInit()。该函数在system_efm32g.c中定义，且没有任何内容是个空函数，提供这个空函数旨在调用应用程序前为用户根据提供一个函数接口来完成系统的硬件初始化（时钟，flash等）。SystemInit()完成之后，IAR就把大权交给了__iar_program_start这个IAR提供的“内部函数”了，我们就跟紧这个__iar_program_start跳转，看看IAR做了什么。

我们看到IAR提供了__low_level_init这个函数进行了“底层”的初始化，进一步跟踪，我们可以查到__low_level_init这个函数做了些什么？

__low_level_init出乎想象的简单，只是往R0寄存器写入了1，就立即执行"BX LR"回到调用处了，接下来，__iar_program_start检查了R0是否为0，为0，则执行_call_main，若不是0，就执行__iar_data_init3。我在IAR
的安装目录IAR Systems\Embedded Workbench 6.0 Kickstart\arm\src\lib下找到了IAR提供的该函数的sketch，程序内容如下：

[cpp] view plain copy print?

1. __interwork int __low_level_init(void)  

2. {  

3.   /*==================================*/  

4.   /*  Initialize hardware.            */  

5.   /*==================================*/  

6.    /* Choose if segment initialization */  

7.   /* should be done or not.           */  

8.   /* Return: 0 to omit seg_init       */  

9.   /*         1 to run seg_init        */  

10.    return 1;  

11. }  

很明显，这个函数的目的是让用户选择是否完成变量的初始化工作。如果不需初始化，可以令其return 0 。那么程序就直接_call_main跳入main函数了。至于如何修改，参见EWARM development Guide。我们这里选择初始化变量，继续单步运行，程序进入__iar_data_init3,汇编代码如下

当程序运行到 0x5480 :0x42a1CMPR1，R4；通过查看寄存器R1的值为0x00005490，R4的值为0x000054b4，这恰好是Region#Table#Base的开始地址和结束地址。程序继续往下走，如果R1=R4，则弹出R4和LR，直接进入main。显然R1此时不等于R4，且继续往下运行R0=R1+4，将R1地址中的内容装载至R2（即从(Region#Table#Base)取出一个参数送人R2），再令R1=R1+R2，跳转至R1地址处即进到__iar_zero_init3函数。

在__iar_zero_init中，取出(Region#Table#Base)中的第一个参数放入R1，另一个参数放入R2。同时R0进行了两次后索引，即R0=R0+8。通过查看寄存器，R2为0x200000AC，为该系统的RAM区。存在循环：

[cpp] view plain copy print?

1. 0X3B8       MOVS R3 ,#0  

2. 0X3BA       STR.W   R3, [R2],   #0X04  

3. 0X3BE       SUBS    R1, R1, #0X04  

4. 0X3C0       BNE.N   0X3B8  

5. 即  

6. for(;R1!=0;R2=R2+4,R1=R1-4)  

7. {  

8. *R2 = 0  

9. }  

可以看出，该函数是将一段内存区域清零，其中R2为内存区域的首地址，R1为清零内存区域的大小。清零完成后，又回到__iar_data_init3。将R0的值赋给R1，此时R1为Region#Table#Base的新的首地址，别忘了在__iar_zero_init从Region#Table#Base取了两个值，R0后索引了两次。程序继续比较R1和R4的值，不相等。再(Region$|$Table$|$Base)取出参数赋给R1，BX R1。程序进入__iar_copy_init3。

可以看出与__iar_zero_init3中取参数的几乎一样：先取出大小，随后取出了地址——只不过这里多出了1个地址，没错这就是"copy"，其中R1为copy字节数目，R2为存储变量初始值的FLASH首地址（source），R3为变量的内存地址区（destination）。复制过程代码循环为：

[cpp] view plain copy print?

1. 0x2612  LDR.W       R4,     [R2],#0X04  

2. 0X2616  STR.W       R4,     [R3],#0X04  

3. 0X261A  SUBS        R1,     R1,#4  

4. 0X261C  BNE.N       0X2612  

5. 即   

6. for(;R1!=0;R2=R2+4,R3=R3+4,R1=R1-4)  

7. {  

8. *R3 = *R2;  

9. }  

读到这里，我们应该可以猜到IAR的意图了：__iar_data_init3一开始加载了0x0800'7C78至R0，0x0800'7C9C至R4，[R0,R4]就是一段启动代码区，在这个区域内保存了要“处理”的所有地址与信息——执行的函数地址或者参数，实际上，这片区域也有一个名字，叫做：(Region#Table#Base)。在这个区域内，程序以R0为索引，R4为上限，当R0=R4，__iar_data_init3执行完毕，跳转至main()函数。

1.4 总结
通过上述分析我们可以看到Region#Table#Base保存了__iar_data_init3、__iar_data_copy的地址，同时还有函数所需的__iar_data_init3的FLASH地址和清零字节的个数、以及__iar_data_copy源地址和目的地址以及复制的字节个数信息。
总之，IAR在启动main()函数以前，执行了Reset_Handler，调用SystemInit()，并转入__iar_program_start中执行__low_level_init与__iar_data_init3，并在__iar_data_init3中，先后调用__iar_zero_init3与__iar_copy_init3对全局变量、全局已初始化变量进行相应的初始化操作。最后，调用main()函数执行。

1.5 思考
思考1
为什么进入__iar_data_init3和__iar_data_copy时，只选择将R4,和LR压栈？
压栈R4可以很简单的理解，因为程序中用到了该寄存器，所以在进入调用函数时把它压入栈保护，但是为什么不压栈R0-R3呢？网上搜了一遭，发现得从ATPCS （ ARM-THUMB procedure call standard）说起。其中ATPCS规定寄存器使用有如下规则：
1. 子程序间通过寄存器 R0-- R3 来传递参数，被调用的子程序在返回前无需恢复寄存器 R0-R3 的内容。
2. 在子程序中，使用寄存器 R4 R11 来保存局部变量。 如果在子程序中使用到了其中的寄存器 ， 子程序进入时必须保存这些寄存器的值， 在返回前必须恢复这些寄存器的值； 对于子程序中没有用到的寄存器则不必进行这些操作。


思考2
__iar_data_init3、__iar_data_copy和__low_level_init这些函数在哪里？
之前在iar的安装目录IAR Systems\Embedded Workbench 6.0 Kickstart\arm\src\lib下找了很久，都没有找到__iar_data_init3、__iar_data_copy这两个函数，对于__low_level_init，我工程里面也没有设置改文件的包含路径。所以敢肯定，启动代码中调用的函数非这个函数。

最后，通过设置project->options->linker->list。选中Module selection。重新编译工程。在工程目录debug->list文件下找到*.log文件，查看链接器的链接日志。在*.log文件中详细列举了每个目标文件的load目录和import和definition symbol。在这个文件里，终于找到了它们的身影。

可以看到，链接器都是从rt7M_t1.a文件中调用的各个已经编译好的目标*.o文件。rt7M_t1.a是啥玩意？只是IAR提供的预先已经编译好的库文件。其中7M表示体系结构为V7M，t代表指令集为thumb指令集，l表示存储为小端。rt为runtime，这类库文件一般系统启动，初始化，浮点AEABI有关的库。所有上述用到的库函数都可以自己定制，因为定制库函数是一个非常复杂的过程，所以的慎重思考是否有必要定制！