M3启动文件.tmp

目录

第1章CMSIS标准 (1)

1.1 CMSIS标准简介 (1)

1.2 CMSIS标准的软件架构 (1)

1.3 CMSIS标准的文件结构 (2)

第2章注解startup.s文件（以startup_LPC17xx.s为例） (3)

2.1 堆栈以及堆的初始化 (3)

2.1.1 堆栈的初始化 (3)

2.1.2 堆的初始化 (3)

2.2 中断向量表的初始化 (4)

2.3 调用Reset Handler (5)

2.4 其他的代码 (5)

第3章ARM芯片的启动过程详解 (7)

3.1 ARM芯片的启动过程概述 (7)

3.2 结合代码来看ARM芯片的启动过程 (8)

3.2.1 调试环境的搭建及测试代码 (8)

3.2.2 跟踪启动代码 (8)

3.2.3 详细的启动过程 (9)

3.2.4 __main (10)

3.2.5 __rt_entry (10)

3.2.6 __rt_lib_init (11)

3.3 关于microlib (11)

3.4 x.map (11)

3.4.1 关于链接器 (12)

3.4.2 RW段在RAM的存放 (12)

3.5 关于ARM程序的Memory管理 (12)

3.5.1 ARM镜像文件的组成（image） (12)

3.5.2 关于image文件（镜像文件） (13)

3.5.3 RO段 (13)

3.5.4 RW段 (14)

3.5.5 ZI段（初始化为0或未初始化的变量） (15)

3.6 缺省内存映射 (16)

3.7 内存模型 (17)

第4章关于分散加载文件 (18)

4.1 什么时候使用分散加载文件 (18)

4.2 适用范围 (18)

4.3 再谈ARM Image（镜像文件） (18)

4.4 节放置 (19)

4.5 一个简单的加载过程 (20)

4.6 分散加载文件语法 (21)

4.6.1 加载时域（区）描述 (21)

4.6.2 运行时域（区）描述 (22)

4.6.3 输入段描述 (23)

4.7 实战测试（一个简单的例程） (24)

4.8 实战分散加载 (26)

4.8.1 多块RAM的分散加载文件配置 (27)

4.8.2 多块Flash的分散加载文件配置 (28)

第5章编写自己的启动代码（基于LPC17xx） (32)

5.1 最简单的启动代码（Startup.s Version-1.0） (32)

5.1.1 启动代码必须完成的三项工作 (32)

5.1.2 程序实现（Startup.s Version-1.0） (32)

5.1.3 指定加载方式让程序跑起来 (33)

5.1.4 V ersion-1.0的缺点 (33)

5.2 一个实用的启动代码（Startup.s V ersion-2.0） (33)

5.2.1 设计描述 (33)

5.2.2 程序实现（Startup.s） (34)

5.2.3 向量表V ectors.h和V ectors.c (34)

5.2.4 指定加载方式 (37)

第1章CMSIS标准

1.1 CMSIS标准简介

ARM公司于2008年11月12日发布了ARMCortex微控制器软件接口标准CMSIS 1.0。CMSIS是独立于供应商的Cortex-M处理器系列硬件抽象层，为芯片厂商和中间件供应商提供了简单的处理器软件接口，简化了软件复用工作，降低了Cortex-M上操作系统的移植难度，并减少了新入门的微控制器开发者的学习曲线和新产品的上市时间。

根据近期的调查研究，软件开发已经被嵌入式行业公认为最主要的开发成本。因此，ARM 与Atmel、IAR、KEIL、Luminary Micro、Micrium、NXP、SEGGER和ST等诸多芯片和软件工具厂商合作，将所有Cortex芯片厂商的产品的软件接口标准化，制定了CMSIS标准。此举意在降低软件开发成本，尤其针对进行新设备项目开发或将已有的软件移植到其他芯片厂商提供的基于Cortex处理器的微控制器的情况。有了该标准，芯片厂商就能够将他们的资源专注于对其产品的外设特性进行差异化，并且能够消除对微控制器进行编程时需要维持的不同的、互相不兼容的标准的需求，从而达到降低开发成本的目的。

1.2 CMSIS标准的软件架构

图1.1 基于CMSIS标准的软件架构

从图1.1 基于CMSIS标准的软件架构中可以看到，基于CMSIS标准的软件架构主要分为以下四层：用户应用层，操作系统层，CMSIS层以及硬件寄存器层。其中CMSIS层起着承上启下的作用，一方面该层对硬件寄存器层进行了统一的实现，屏蔽了不同厂商对Cortex-M系列微处理器核内外设寄存器的不同定义，另一方面又向上层的操作系统和应用层提供接口，简化了应用程序开发的难度，使开发人员能够在完全透明的情况下进行一些应用程序的开发。也正是如此，CMSIS层的实现也相对复杂，下面将对CMSIS层次结构进行剖析。

CMSIS层主要分为以下3个部分：

l核内外设访问层（CPAL，Core Peripheral Access Layer）：该层由ARM负责实现包括对寄存器名称、地址的定义，对核寄存器、NVIC、调试子系统的访问接口定义以及

对特殊用途寄存器的访问接口（例如：CONTROL，xPSR）定义。由于对特殊寄存

器的访问以内联方式定义，所以针对不同的编译器ARM统一用__INLINE来屏蔽差

异。该层定义的接口函数均是可重入的。

l片上外设访问层（DPAL, Device Peripheral Access Layer）：该层由芯片厂商负责实现。

该层的实现与CPAL类似，负责对硬件寄存器地址以及外设访问接口进行定义。该

层可调用CPAL层提供的接口函数同时根据设备特性对异常向量表进行扩展，以处

理相应外设的中断请求。

l外设访问函数（AFP , Access Functions for Peripherals）：该层也由芯片厂商负责实现，主要是提供访问片上外设的访问函数，这一部分是可选的。

对一个Cortex-M微控制系统而言，CMSIS通过以上三个部分实现了：l定义了访问外设寄存器和异常向量的通用方法；

l定义了核内外设的寄存器名称和核异常向量的名称；

l为RTOS核定义了与设备独立的接口，包括Debug通道。

这样芯片厂商就能专注于对其产品的外设特性进行差异化，并且消除他们对微控制器进行编程时需要维持的不同的、互相不兼容的标准需求，以达到低成本开发的目的。

1.3 CMSIS标准的文件结构

图1.2 CMSIS的文件基本组织结构

如上图5.2中core_cm.c以及core_cm.h中位内核外设访问层，其中定义了内核中的外设地址以及一些内核的访问及控制函数。

Startup_.s文件是系统的启动文件，其包括堆和栈的初始化配置、中断向量表的配置以及将程序引导到main()函数等功能。

而system_.h和system_.c文件则是由ARM公司提供模板，各芯片制造商根据自己芯片的特点来编写的。

第2章注解startup.s文件（以startup_LPC17xx.s为例）

下面以startup_LPC17xx.s为例，简单看一下CMSIS中的启动代码完成了哪些工作。

主要完成了三项工作：

l堆栈以及堆的初始化；

l定位中断向量表；

l调用Reset Handler。

2.1 堆栈以及堆的初始化

2.1.1 堆栈的初始化

程序清单2.1 startup_LPC17xx.s中的堆栈初始化代码

Stack_Size EQU 0x00000200

AREA STACK, NOINIT, READWRITE, ALIGN=3

Stack_Mem SPACE Stack_Size

__initial_sp

Stack_Size EQU 0x00000200，这个语句相当于Stack_Size这个标号（标号：链接器的术语，下文中提到的所有“标号”，指的都是链接器中的标号）等于0x00000200，相当于C语言中的#define Stack_Size 0x00000200，也就是说此语句只是一个声明，并未分配地址。

AREA STACK, NOINIT, READWRITE, ALIGN=3，此语句定义了一个名叫ST ACK的代码段，并指明8字节对齐（ALIGN=3）。

Stack_Mem SPACE Stack_Size，为Stack_Mem分配Stack_Size大小的一块内存区域，注意这里分配的是RAM。

__initial_sp

此标号有一层隐含的意思那就是在M3中堆栈是满递减堆栈，因为它指定了堆栈指针位于堆栈的高地址（在Stack_Mem之后），具体如下图所示。

图2.1 堆栈指针SP位置

上图来自一个LPC1700工程的.map文件。可以看出栈的起始地址为0x10001f70，大小为512字节（即0x00000200 = Stack_Size）。而堆栈指针的位置在0x10002170，其等于栈的起始地址0x10001f70 + 0x00000200，说明LPC1700系列的Cortex-M3微控制器的堆栈为满递减堆栈。

2.1.2 堆的初始化

程序清单2.2 startup_LPC17xx.s中的堆初始化代码

Heap_Size EQU 0x00000200

AREA HEAP, NOINIT, READWRITE, ALIGN=3

__heap_base

Heap_Mem SPACE Heap_Size

__heap_limit

具体过程与栈的初始化相同。

2.2 中断向量表的初始化

程序清单2.3 中断向量表的初始化代码

PRESERVE8

THUMB

AREA RESET, DA TA, READONLY

EXPORT __V ectors

__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

DCD 0 ; Reserved

DCD 0 ; Reserved

......（以下代码省略）

PRESERVE8指定了以下的代码位8字节对齐，这是keil编译器的一个编程要求，对齐情况如下图所示：

图2.2 .list文件中的8字节对齐示意图

THUMB指定了接下来的代码为THUMB指令集。

AREA RESET, DATA, READONLY，此语句声明RESET数据段。

EXPORT __Vectors，导出向量表标号，EXPORT作用类似于C语言中的extern。之后的代码就是为向量表分配存储区域。

2.3 调用Reset Handler

程序清单2.4 调用Reset Handler的代码

Reset_Handler PROC

EXPORT Reset_Handler [WEAK]

IMPORT __main

LDR R0, =__main

BX R0

ENDP

此段代码只完成了一个功能，引导程序进入__main。__main的具体行为在第三章中有具体的描述。

2.4 其他的代码

程序清单 2.5 CRP加密级别

IF : LNOT::DEF:NO_CRP

AREA |.ARM.__at_0x02FC|, CODE, READONL Y

CRP_Key DCD 0xFFFFFFFF

ENDIF

此段代码指定了接下来的代码存储与0x02FC的地址，具体情况如下图所示。

这段代码是NXP公司的LPC1700系列的MCU特有的一段代码，其他公司的Cortex-M3 MCU的启动程序是没有这段代码的。

这段代码是指定LPC1700的CRP加密级别的代码段，芯片上电后会自动读取这一地址的值以确定加密方式，其中CRP_Key = 0xffffffff为不加密（0级加密），CRP_Key = 0x12345678为1级加密，CRP_Key = 0x87654321为2级加密，CRP_Key = 0x43218765为3级加密（最高级加密），3级加密将会禁止所有的ISP指令，也就是说，芯片将不能读写、不能擦除。

程序清单 2.6 具体的堆栈以及堆的初始化行为

; User Initial Stack & Heap

IF :DEF:__MICROLIB

EXPORT __initial_sp

EXPORT __heap_base

EXPORT __heap_limit

ELSE

IMPORT __use_two_region_memory

EXPORT __user_initial_stackheap

__user_initial_stackheap

LDR R0, = Heap_Mem

LDR R1, =(Stack_Mem + Stack_Size)

LDR R2, = (Heap_Mem + Heap_Size)

LDR R3, = Stack_Mem

BX LR

关于此段代码将在第三章有具体叙述，在此略过。

第3章ARM芯片的启动过程详解

“ARM程序”是指在ARM系统中正在执行的程序，而非保存在ROM中的bin映像（image）文件。这一点清注意区别。

一个ARM程序包含3部分：RO，RW和ZI

l RO就是只读数据，是程序中指令和常量；

l RW是可读写的数据，程序中已初始化变量；

l ZI是程序中未初始化的变量和初始化为0的变量。

由以上3点说明可以理解为：

l RO就是readonly；

l RW就是read/write；

l ZI就是zero。

3.1 ARM芯片的启动过程概述

图3.1 ARM芯片的启动过程详解

注意，以上的过程并非绝对的，不同的ARM架构或是不同的代码以上的执行过程是不同的。

复位处理程序是在汇编器中编写的短模块，系统一启动就立即执行。复位处理程序最少要为应用程序的运行模式初始化堆栈指针。对于具有本地内存系统（如缓存、TCM、MMU和MPU）的处理器，某些配置必须在初始化过程的这一阶段完成。复位处理程序在执行之后，通常跳转到__main以开始C库初始化序列。

__main负责设置内存，而__rt_entry负责设置运行时环境。__main执行代码和数据复制、解压缩以及ZI数据的零初始化。然后，它跳转到__rt_entry，设置堆栈和堆、初始化库函数和静态数据，并调用任何顶级C++构造函数。然后，__rt_entry跳转到应用程序的入口main()。主应用程序结束执行后，__rt_entry将库关闭，然后把控制权交还给调试器。函数标签main()具有

特殊含义。main()函数的存在强制链接器链接到__main和__rt_entry中的初始化代码。如果没有标记为main()的函数，则没有链接到初始化序列，因而部分标准C库功能得不到支持。

3.2 结合代码来看ARM芯片的启动过程

3.2.1 调试环境的搭建及测试代码

使用keil for ARM（uVision4）的软件模拟，工程的硬件设定为LPC1700系列，不使用microlib。这里不使用microlib，则系统自动加载标准C Library，这样我们才能看到标准的ARM 芯片的标准启动过程。随后我们会对microlib进行探讨。

测试代码如下：

程序清单3.1 启动过程测试代码

#include "LPC17xx.h" /* LPC17xx外设寄存器*/

int main (void)

{

SystemInit(); /* 系统初始化，切勿删除*/

while (1) {

}

}

我们的测试代码使用的是一段最简单的代码，代码本身只包含CMSIS标准的必备文件，即stdint.h、core_cm3.h、core_cm3.c、system_LPC17xx.h、system_LPC17xx.c、LPC17xx.h、startup_LPC17xx.s和main.c。

3.2.2 跟踪启动代码

开始调试之前，须将工程设置的DEBUG栏中取消掉Run to main()的勾选，否则代码会直接运行到main()函数，我们也就无法看到芯片的启动过程了。

然后启动调试，最先进入Reset_Handler，如下图所示。

图3.2 Reset_Handler

继续单步运行，程序跳入__main（C Library的代码，并非用户代码），如下图所示。

图3.3 __main

继续单步运行，经过一系列的代码（主要是scatter load过程）后，程序进入__rt_entry（同样是由C Library管理，并非用户代码）。

图3.4 __rt_entry

继续单步运行，再次经过一系列的代码之后（主要是堆栈和堆的初始化以及C Library的初始化），程序进入main()。如下图所示。

图3.5 进入main函数

以上是整个测试代码启动过程的跟踪调试的大致过程，这个过程对ARM系列的芯片来说都是相同的，不同的是里面具体的细节。

3.2.3 详细的启动过程

使用的依然是上面的测试代码，详细启动过程如下图所示。

图3.6 芯片启动的详细过程

上图显示的就是测试代码在LPC17xx上启动运行的全过程（详细过程），由此图可见LPC17xx的启动过程与图3.1所示的启动过程是基本一致的，但是还有差别，可以说是图3.1所示启动过程的简化版。

注意：并非所有代码的启动过程全部相同，此启动过程与所使用的链接器、用户代码以及其所集成的C Library密切相关。此图为由“armlink”的链接器为程序清单3.2所示的测试代码产生的启动过程，其他情况可能会有一些差异（比如有的代码的启动过程就会运行一段RW 段的解压代码等，而本例程中则没有）。

3.2.4 __main

若程序使用的是C或C++语言编写的代码，那么C/C++程序的入口是在C Library中的__main。库代码在此处执行以下操作。

l1将非根（RO和RW）执行区从其加载地址复制到执行地址（这里的根区指的就是__main和__rt_entry）。另外，如果压缩了任何数据节，则会将它们从加载地址解压

缩到执行地址（此数据压缩及解压缩过程并不是对所有代码都会执行）；

l将ZI区清零；

l跳转到__rt_entry。

3.2.5 __rt_entry

__rt_entry符号是使用ARM C库的程序的起点。将所有分散加载区重定位到其执行地址后，会将控制权传递给__rt_entry。其有如下缺省实现：

l设置堆和堆栈。

l调用__rt_lib_init以初始化C Library。

l调用main()。

l调用__rt_lib_shutdown以关闭C Library。

l退出。

注意：最后两步是在程序退出main()函数时才会执行，而嵌入式程序一般都是死循环，所以基本不会执行这两个过程。还有，以上过程是对标准C Library而言，不包括使用microlib 的情况。

3.2.6 __rt_lib_init

这是库初始化函数，它与__rt_lib_shutdown()配合使用。

这是库初始化函数。它是紧靠__rt_stackheap_init()后面调用的，并传递一个要用作堆的初始内存块。此函数是标准ARM库初始化函数，不能重新实现此函数。

3.3 关于microlib

microlib是缺省C库的备选库。它旨在与需要装入到极少量内存中的深层嵌入式应用程序配合使用。这些应用程序不在操作系统中运行。microlib进行了高度优化以使代码变得很小。它的功能比缺省C库少，并且根本不具备某些ISO C特性。某些库函数的运行速度也比较慢，例如，memcpy()。

microlib 与缺省C库之间的主要差异是：

l microlib不符合ISO C库标准。不支持某些ISO特性，并且其他特性具有的功能也较少；

l microlib不符合IEEE 754二进制浮点算法标准；

l microlib进行了高度优化以使代码变得很小；

l无法对区域设置进行配置。缺省C区域设置是唯一可用的区域设置；

l不能将main()声明为使用参数，并且不能返回内容；

l不支持stdio，但未缓冲的stdin、stdout和stderr除外；

l microlib对C99函数提供有限的支持；

l microlib不支持操作系统函数；

l microlib不支持与位置无关的代码；

l microlib不提供互斥锁来防止非线程安全的代码；

l microlib不支持宽字符或多字节字符串；

l与stdlib不同，microlib不支持可选择的单或双区内存模型。microlib只提供双区内存模型，即单独的堆栈和堆区。

3.4 x.map

想要更好的了解启动代码的运行机制，我们就有必要了解一下由Keil的链接器“armlink”生成的描述文件即x.map文件。

3.4.1 关于链接器

图3.7 目标文件的组成

上图即是armlink的链接器为程序清单3.1所示的测试代码生成的.map文件中的一部分，其描述了镜像文件的组成信息，其中可以明显的看到其由两部分构成：

l由User Code生成的目标文件；

l由C Library生成的目标文件。

可见我们在上文中所描述的启动过程中看到的__main、__rt_entry、__scatterload以及__rt_lib_init等，就是C Library中的代码。

同理，我们每次烧录的可执行的ARM的bin文件中不仅有开发者编写的代码，还有 C Library的代码。

3.4.2 RW段在RAM的存放

图3.8 由armlink生成的RW段在RAM中存放的描述

3.5 关于ARM程序的Memory管理

3.5.1 ARM镜像文件的组成（image）

所谓ARM映像文件就是指烧录到ROM中的bin文件，也成为image文件。以下用Image 文件来称呼它。Image文件包含了RO和RW数据（注意：不包含ZI数据）。之所以Image文

件不包含ZI数据，是因为ZI数据都是0，没必要包含，只要程序运行之前将ZI数据所在的区域（执行区域）一律清零即可。包含进去反而浪费存储空间。

3.5.2 关于image文件（镜像文件）

从以上两点可以知道，烧录到ROM中的image文件与实际运行时的ARM程序之间并不是完全一样的。因此就有必要了解ARM程序是如何从ROM中的image到达实际运行状态的。实际上，RO中的指令（启动程序）至少应该有这样的功能：

l将RW从ROM中搬到RAM中，因为RW是变量，变量不能存在ROM中。

l将ZI所在的RAM区域全部清零，因为ZI区域并不在Image中，所以需要程序根据编译器给出的ZI地址及大小来将相应得RAM区域清零。ZI中也是变量，同理：变

量不能存在ROM中。

在程序运行的最初阶段，RO中的指令（启动程序）完成了这两项工作后（也就是分散加载的过程）C程序才能正常访问变量。否则只能运行不含变量的代码。说了这么多可能还是有些迷糊，RO，RW和ZI到底是什么，下面我将给出几个例子，最直观的来说明RO，RW，ZI 在C语言中的含义。

3.5.3 RO段

看下面两段程序，它们之间差了一条语句，这条语句就是声明一个字符常量。因此按照之前的内容，它们之间应该只会在RO数据中相差一个字节（字符常量为1字节）。

Prog1：

#include

void main(void)

{

;

}

Prog2：

#include

const char a = 5；

void main(void)

{

;

}

Prog1编译出来后的信息如下（来自.map文件）：

==============================================================

Code RO Data RW Data ZI Data Debug

948 60 0 96 0 Grand Totals

==============================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

==============================================================

Prog2编译出来后的信息如下（来自.map文件）：

==============================================================

Code RO Data RW Data ZI Data Debug

948 61 0 96 0 Grand Totals

==============================================================

Total RO Size(Code + RO Data) 1009 ( 0.99kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1009 ( 0.99kB)

============================================================== 以上两个程序编译出来后的信息可以看出：Prog1和Prog2的RO包含了Code和RO Data 两类数据。他们的唯一区别就是Prog2的RO Data比Prog1多了1个字节。这正和之前的推测一致。如果增加的是一条指令而不是一个常量，则结果应该是Code数据大小有差别。

3.5.4 RW段

同样再看两个程序，它们之间只相差一个“已初始化的变量”，按照之前所讲的，已初始化的变量应该是算在RW中的，所以两个程序之间应该是RW大小有区别。

Prog3：

#include

void main(void)

{

;

}

Prog4：

#include

char a = 5；

void main(void)

{

;

}

Prog3编译出来后的信息如下（来自.map文件）：

==============================================================

Code RO Data RW Data ZI Data Debug

948 60 0 96 0 Grand Totals

==============================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

============================================================== Prog4编译出来后的信息如下（来自.map文件）：

==============================================================

Data RO Data RW Data ZI Data Debug

948 60 1 96 0 Grand Totals

==============================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 97 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1009 ( 0.99kB)

============================================================== 以上两个程序编译出来后的信息可以看出：Prog1和Prog2的RO包含了Code和RO Data 两类数据。他们的唯一区别就是Prog2的RO Data比Prog1多了1个字节。这正和之前的推测一致。如果增加的是一条指令而不是一个常量，则结果应该是Code数据大小有差别。

3.5.5 ZI段（初始化为0或未初始化的变量）

再看两个程序，他们之间的差别是一个未初始化的变量“a”，从之前的了解中，应该可以推测，这两个程序之间应该只有ZI大小有差别。

Prog3：

#include

void main(void)

{

;

}

Prog4：

#include

char a；

void main(void)

{

;

}

Prog3编译出来后的信息如下（来自.map文件）：

==============================================================

Code RO Data RW Data ZI Data Debug

948 60 0 96 0 Grand Totals

==============================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 96 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 ( 0.98kB)

==============================================================

Prog4编译出来后的信息如下（来自.map文件）：

==============================================================

Code RO Data RW Data ZI Data Debug

948 60 0 97 0 Grand Totals

==============================================================

Total RO Size(Code + RO Data) 1008 ( 0.98kB)

Total RW Size(RW Data + ZI Data) 97 ( 0.09kB)

Total ROM Size(Code + RO Data + RW Data) 1008 (0.98kB)

============================================================== 编译的结果完全符合推测，只有ZI数据相差了1个字节。这个字节正是未初始化的一个字符型变量“a”所引起的。

注意：如果一个变量被初始化为0，则该变量的处理方法与未初始化华变量一样放在ZI 区域。即：ARM C程序中，所有的未初始化变量都会被自动初始化为0。

以上代码是再ADS下编译的，keil环境下与之不同，比如在keil下生成ZI数据段就必须定义一个大于8字节的未初始化或初始化位0的变量，且必须在源代码中引用此变量才会在链接的描述文件中看到其生成的ZI文件。

3.6 缺省内存映射

对于没有描述内存映射的映像，链接器根据缺省内存映射放置代码和数据。如下图所示。

图3.9 缺省内存映射

创建一个可以在其中执行C或C++程序的环境。这包括：

l创建一个堆栈；

l创建一个堆（如果需要）；

l初始化程序所用的库的部分组成内容；

l调用main()以开始执行程序；

l支持程序使用ISO定义的函数；

l捕获运行时错误和信号，如果需要，还可以在出现错误或程序退出时终止执行。

注意：这个内存映射并非对所有芯片都有效，不同的芯片的内存映射是不同的。在Cortex-M3中的内存映射与上图是一致的。

3.7 内存模型

在Keil for ARM下你可以选择以下任意内存模型：

1．单内存区

堆栈从内存区顶部向下增长。堆从内存区底部向上增长。这是缺省设置。由堆管理的内存从来不会缩减。不能将通过调用free()释放的堆内存再次用于其他用途。

2．双内存区

一个内存区用于堆栈，另一个内存区用于堆。堆区大小可以是零。堆栈区可以位于分配的内存中，也可以从执行环境中继承。要使用双区模型而不是缺省的单区模型，请使用以下任一方法：

l汇编语言中的IMPORT __use_two_region_memory；

l C中的#pragma import(__use_two_region_memory)。

例如下图所示，此代码来自startup_LPC17xx.s。

如果使用双区内存模型，并且未提供任何堆内存，则无法调用malloc()、使用stdio或获取main()的命令行参数。如果将堆区大小设置为0，并且将__user_heap_extend()定义为可扩展堆的函数，则会在需要时创建堆。

第4章关于分散加载文件

4.1 什么时候使用分散加载文件

l存在复杂的地址映射：例如代码和数据需要分开放在在多个区域。

l存在多种存储器类型：例如包含Flash、ROM、SDRAM快速SRAM。我们根据代码与数据的特性把他们放在不同的存储器中，比如中断处理部分放在快速SRAM内部

来提高响应速度，而把不常用到的代码放到速度比较慢的Flash内。

l函数的地址固定定位：可以利用Scatter file实现把某个函数放在固定地址，而不管其应用程序是否已经改变或重新编译。

l利用符号确定堆与堆栈：

l内存映射的IO：采用scatter file可以实现把某个数据段放在精确的地指处。

因此对于嵌入式系统来说scatter file是必不可少的，因为嵌入式系统采用了ROM，RAM，和内存映射的IO。通过使用分散加载机制，可以使用文本文件中的描述为链接器指定映像的内存映射。分散加载为您提供了对映像组件分组和位置的全面控制。分散加载可以用于简单映像，但它通常仅用于具有复杂内存映射的映像，即多个区在加载和执行时分散在内存映射中。

4.2 适用范围

有时候用户希望将不同代码放在不同存储空间，也就是通过编译器生成的映像文件需要包含多个域，每个域在加载和运行时可以有不同的地址。要生成这样的映像文件，必须通过某种方式告知编译器相关的地址映射关系。

Scattter loading是ARM连接器（armlink）提供的一种机制，该机制让你能够把可执行映像文件分成多个区域，然后分别为它们指定在存储器上的存储位置。Scatter loading机制用于定位装载区域和运行区域在分离的存储映像中的位置。

4.3 再谈ARM Image（镜像文件）

ARM中的源文件经过编译器编译生成的目标文件.obj（Object file）和相应的C/C++运行时库（Runtime Library）经过连接器的处理后，生成ELF格式的映像文件（image）——它可以被写入目标设备的ROM中直接运行或加载后运行。

镜像文件的组成如图所示。