AT91RM9200处理器的启动机制

2009/8/12重新生产一批板子后,发现在写入boot.bin和u-boot后,外部启动超级终端没有观测到任何现象,很郁闷.在网上搜一下,发现以下好

文章:

 

1.引言
在开发基于AT91RM9200 处理器的嵌入式系统时，以何种方式启动系统是一个
首先要考虑的基本问题。庆幸的是，AT91RM9200 处理器提供了各种各样的启动
方式，总体上可分为从外部的DATAFLASH、二线EEPROM 或8 位并行存储器
引导启动和从内部的BOOTROM 引导启动两种情况。当从外部存储器启动时，
存储器中的启动代码又是从那里来的呢？有3 种手段，可以直接通过编程器将启
动代码写入外部存储器，也可以通过JTAG 接口从主机下载到目标系统的闪存芯
片，还可以由AT91RM9200 处理器的内部BOOTROM 启动系统与主机建立通信
并下载所需代码再写入闪存芯片。那么当从内部的BOOTROM 启动时，所需的
启动代码又是如何得到的呢？很简单，芯片厂商在生产芯片时就嵌入了这段代
码。内嵌的启动代码被存储在AT91RM9200 处理器的片内ROM 中，片内ROM
的起始物理地址是0x0010_0000，片内SRAM 的起始物理地址为0x0020_0000。
我们都知道ARM 处理器启动时会产生复位异常，程序计数器PC 指向复位异常
向量地址0x0000_0000，也就是说启动时首先执行的是位于地址0x0000_0000 处
的指令。因此从0x0000_0000 到0x0010_0000 的1M 的内部存储区域（内部存储
区0）在上电启动时的代码将决定系统的启动过程。那么是应该由外部存储器中
的启动代码来占据内部存储区0 以实现外部启动，还是应该由位于0x0010_0000
（内部存储区1）处的ROM 中的内嵌启动代码来占据这一空间以实现内部启动
呢？这就需要一个仲裁机制来进行选择。这就是AT91RM9200 芯片的PA31/BMS
引脚（在PQFP 封装中为79 脚，在BGA 封装中为A10 脚）。BMS 即Boot Mode
Select（启动模式选择），若BMS=1，则将内部存储区1 的数据映射至内部存储
区0，即从内部的ROM 启动；若BMS=0，则将外部存储器的区域0 映射至内部
存储区0，即从外部存储器启动。需要注意的是只有在上电启动时，该引脚具有
启动模式选择的功能，此后便成为标准的I/O 接口PA31。令BMS=1 进行启动，
则会在内部存储区0 和1 中具有完全相同的代码，即执行内部启动程序。内部启
动程序主要包括两大部分：BootLoader 和Boot Uploader。
2．BootLoader
BootLoader 首先被执行，它要做的第一件事就是进行设备初始化，主要包括：
通过设定PMC（Power Management Controller）中的相应寄存器得到主振荡器的
频率和用于PLLB（Phase Lock Loop B）的合适的分频，从而使PLLB 输出一
48MHz 的时钟信号，该信号是用于USB 设备的必需时钟。 为各种ARM 模式
建立堆栈。 检测主振荡器频率。 设定中断控制器。 初始化C 变量。
跳转到ma in 函数执行。接下来BootLoader 的任务就是在片外“非挥发”的存储器
中寻找有效的可执行代码，这些有效代码可以是应用程序也可以是第二级引导装
入程序。查找有效代码的顺序是先查找与SPI（Seria l Periphera l Interface）的
NPCS0 连接的串行DATAFLASH，然后是与TWI（Two-Wire Interface）相连的
串行EEPROM 和连向EBI（External Bus Interface）的NCS0 的8 位并行存储器。
在查找串行DATAFLASH 与串行EEPROM 时需先发送一个读指令，然后根据是
否收到设备准备好的ACK（应答使能）信号决定是否继续在该设备上查找。查
找有效的可执行代码的依据是分析相应存储器的开始32 字节的代码，这是因为
如果某存储器的代码有效，则该存储器的代码将被下载到AT91RM9200 处理器
的片内SRAM 的起始地址（ 0x0020_0000 ）处， 随后该地址就会被映射到
0x0000_0000 并执行。也就是说，外部存储器的起始32 字节的内容其实就是ARM
的异常向量入口处应执行的代码，通常情况下，该处内容应为跳转指令以使当
ARM 发生异常时转向不同的处理程序进行处理。所以，如果某存储器的起始32
字节中是ARM 的跳转指令代码或向PC 寄存器装入偏移地址的指令则认为该存
储器中的代码有效。下面是一个有效异常向量的例子： 00 ea00000b B 0x2c 04
e59ff014 LDR PC,[PC,20] 08 e59ff014 LDR PC,[PC,20] 0C e59ff014 LDR
PC,[PC,20] 10 e59ff014 LDR PC,[PC,20] 14 00001234 LDR PC,[PC,20] 18 e51fff20
LDR PC,[PC,-0xf20] 1C e51fff20 LDR PC,[PC,-0xf20] 找到有效代码后接下来就
是将代码下载到处理器的片内SRAM 中，但是应该下载的代码到哪个位置截止
呢？也就是代码的大小有多少呢？位于起始地址0x18 处的一个字长（ 4 字节）
的代码也就是重新映射后会成为第6 个异常向量的存储单元中包含了所需的信
息。其结构如下表所示： 31 17 16 13 12 8 7 0 存储器页面大小页面位数Nb 保
留要下载的块（ 512 字节）数例如，对于型号为AT45DB642 的DATAFLASH
来说有11776 字节代码要下载，则其第6 异常向量内容为：0x0841A017 （0000
10000 0100 0001 1010 0000 0001 0111b）含义为：要下载的代码大小：0x17×512
字节=11776 字节；存储器页面数（ 1101b）： 13 ==>213=8192 存储器页面大小
（0000 10000 0100 000）=1056 对于串行EEPROM 和8 位并行FLASH，只需计
算其需下载的代码大小即可。对存储器的异常向量分析并得到代码大小的有关信
息后，接下来BootLoader 要做的就是将确定大小的代码下载到处理器片内SRAM
处（ 0x0020_0000），下载完毕则复位处理器外围寄存器并进行存储器的重新映射，
重新映射可通过改写MC_RCR（Memory Controller _ Remap Control Register ）的
RCB 位为1 完成，通过重新映射使片内SRAM 的内容映射到0x0000_0000 处，
然后通过将PC 置0 开始执行下载的应用代码。在上述从AT91RM9200 处理器内
部ROM 启动然后在外部存储器中找到有效的应用代码并下载到片内SRAM 进
行执行的过程中有几点应引起注意： 从片外存储器下载的代码大小应小于处
理器片内SRAM 的大小。 串行EEPROM 在TWI 总线上的物理地址必须为0。
有效代码总是从片外存储器的0x0000_0000 地址处下载到片内SRAM，在重
新映射后下载代码地址为片内0x0000_0000 处。 下载的代码应与其所处存储
位置无关或可链接至地址0x0000_0000 处。 DATAFLASH 必须是与SPI 的
NPCS0 相连。 8 位并行FLASH 必须是与EBI 的NCS0 相连。
3．Boot Uploader
当BootLoader 不能得到串行DATAFLASH 和EEPROM 的ACK 应答或在外部存
储器中找不到有效的可执行代码时，Boot Uploader 便被激活执行。Boot Upload er
的主要任务就是建立外部通信通道并从该通道上传可执行代码到0x0020_0000
的片内SRAM 起始位置处。AT91RM9200 处理器的Boot Uploader 提供了两种通
信的方式，即调试串口和USB 设备接口。Boot Uploader 将调试串口初始化为
115200 波特、8 位数据、无奇偶校验位、1 位停止位并以发送字符“C”（0x43）
的方式启动Xmodem 协议建立通信。任何运行该协议的终端都可用来向目标系
统传送应用代码。在使用USB 设备接口进行通信时需要一个48MHz 的USB 时
钟，这一点已经在设备初始化中通过对PLLB 配置实现了，另外通信时使用的是
DFU（Device Firmware Upgrade）协议，关于这一点请读者参考相关的资料。考
虑到内部启动代码及协议运行使用的变量和堆栈会占用一部分SRAM，在通信建
立后上传时为避免发生错误，应使上传的应用代码应比处理器片内SRAM 的容
量小至少3K。和从外部存储器下载有效代码之后相同，上传完成后便开始复位
外围寄存器、关中断并进行重新映射，映射后片内SRAM 的起始地址成了
0x0000_0000，片内ROM 的地址为0x0010_0000。接下来PC 被置0，于是开始
执行刚刚上传的应用代码。当目标系统采用移植操作系统等较大代码时，仅仅由
片内的有限的SRAM 是不可能满足运行的需要的，因此也不可能由Boot
Uploader 直接将这类代码长传并执行。一般的做法是先上传一段由用户自己开发
的引导代码，该代码独立于嵌入式操作系统且与目标应用程序无关，其主要作用
是初始化硬件系统，特别是片外FLASH 和RAM 等存储器和串行通信口或以太
网接口，从而为将庞大的嵌入式操作系统或应用程序进行可靠快速的上传并能由
足够的空间运行或存储提供先决条件。

 

目前板子主要有以下三个问题：

1、在改用了90纳米技术的FLASH S29GL256P10TFI之后无法正确读出芯片ID，读写在硬件测试程序中有时能正常读写，但U-BOOT无法读写。很奇怪，按理应该和S29GL256N系列兼容啊？读ID的时候总是滞后一个字节。

2、部分板子要么是SDRAM，要么是DDRAM无法正常读写，按照经验应该是某些引脚虚焊了

3、部分板子超级终端在倒进loader后能正常显示出CCCCC，但继续倒进U-BOOT之后，至倒进了一部分就出现了”收到重发命令“，并最终出现了”超过错误极限“的提示.怀疑是SDRAM或CPU某个地方虚焊，因为大于11K的程序都将倒入到SDRAM中运行，所以最有可能是SDRAM没能正常运行导致的。将SDRAM与CPU重新焊过一遍后U-BOOT倒入运行正常。

 

9月25日，重新测试，发现不是FLASH的原因。有以下怪异现象：一块板子前一天测试时FLASH的ID，双口RAM的读写均出现异常，尤其双口RAM,给人的感觉像是总线出现了问题，数据异常混乱无序；但到了第二天早上一测试，居然都好了，双口RAM读写完全正常，FLASH的ID，读写均正常，但反复操作了几次后又出现跟以前一样的现象。郁闷！怀疑是DPLL的参数错误，导致系统时钟不稳定？

9月30日，反复试验证明此前出现的类似于总线浮空的问题是因为一个外接NAND FLASH的与门造成的，本以为CPU的片选信号是输出信号，就算浮空应该也没有什么问题。其实问题就在于NAND FLASH的片选浮空了，导致NAND FLASH影响了系统总线，从而在CPU侧所看到的数据经常出现异常。