STM32 eCos 启动代码分析（一）系统复位
概述
最近接触了STM32，开始了解CortexM3系列ARM处理器上RTOS的移植和启动。
开始总是艰难的，CortexM3是arm7tdmi的升级产品，但实际上和之前的ARM7有着很大的区别。
首先，我们必须有支持CortexM3的编译器，因为CortexM3采用的是Thumb和Thumb2指令集，而不是ARM指令集。
好在eCos 3.0以后ecoscentric提供的toolchain已经支持了CortexM3虽然可能没有采用Thumb2指令集，但是编译和运行eCos是没问题的。
因为CortexM3的中断和异常的特殊性决定了它上面运行的启动代码的不同，这也是为什么我们看到ecos把cortexm的体系结构和之前
的ARM平行放置了。
我们首先看看eCos的第一条语句是怎么运行的，这样我们就比较容易理解后面硬件初始化和中断入口表的代码了。
纵观CortexM启动代码
要了解eCos的CortexM启动代码，需要理清下面几个文件的编译和链接关系。
packages/hal/cortexm/arch/current/src/vector.S
packages/hal/cortexm/arch/current/src/hal_misc.c
packages/hal/cortexm/stm32/stm3210e_eval/current/include/pkgconf/mlt_cortexm_stm3210e_eval_rom.ldi
packages/hal/cortexm/arch/current/src/vector.S
//==========================================================================
.syntaxunified
.thumb
//==========================================================================
//Initial exception vector table
//
//This only contains the stack and entry point for reset. The table
//to be used at runtime is constructed by code in hal_reset_vsr().
.section ".vectors","ax"
.global hal_vsr_table
hal_vsr_table_init:
.long hal_startup_stack // 0 Reset stack
.long hal_reset_vsr // 1 Reset entry
这里我们可以看到，hal_vsr_table_init开始的预留了8个byte，我们可以猜想这个就是系统的启动部分。
但是，要想了解eCos的启动代码，我们必须知道hal_startup_stack和hal_reset_vsr来源于何处如何设定。
//==========================================================================
packages/hal/cortexm/stm32/stm3210e_eval/current/include/pkgconf/mlt_cortexm_stm3210e_eval_rom.ldi
//eCos memory layout
#include<pkgconf/hal.h>
#include<cyg/infra/cyg_type.inc>
MEMORY
{
sram : ORIGIN = 0x20000000, LENGTH =0x00010000-CYGNUM_HAL_COMMON_INTERRUPTS_STACK_SIZE
flash: ORIGIN = 0x08000000, LENGTH = 0x00080000
rom : ORIGIN = 0x64000000, LENGTH = 0x01000000
ram : ORIGIN = 0x68000000, LENGTH = 0x00100000
}
SECTIONS
{
SECTIONS_BEGIN
SECTION_rom_vectors(flash, 0x08000000, LMA_EQ_VMA)
SECTION_RELOCS(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_text(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_fini(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_rodata(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_rodata1(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_fixup(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_gcc_except_table(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_eh_frame(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_got(flash, ALIGN (0x8), LMA_EQ_VMA)
SECTION_sram(sram, 0x20000400, FOLLOWING (.got))
SECTION_data(ram, 0x68000000, FOLLOWING (.sram))
SECTION_bss(ram, ALIGN (0x8), LMA_EQ_VMA)
CYG_LABEL_DEFN(__heap1)= ALIGN (0x8);
SECTIONS_END
}
hal_vsr_table= 0x20000000;
hal_virtual_vector_table= hal_vsr_table + 128*4;
hal_startup_stack= 0x20000000 + 1024*64;
这里我们可以看到，这个链接管理脚本设置了hal_startup_stack的大小。
观察map文件
我们通过arm-eabi-nm这样的工具把elf文件生成几个map文件看一看这些symbol的具体位置。
hal_reset_vsr
hal_startup_stack
hal_reset_vsr是系统初始化的一个重要函数
hal_reset_vsr还调用了stm32变体层的初始化函数hal_system_init。
分析一下生成的binary文件
以ROM类型的二进制文件为例，如果我们把STM32的芯片设定为从内部的ROM启动。
他会默认的执行0x0000000也就是0x0800000，我们通过Linux的ghex来看这个二进制文件的前8个字节。
我们会看到
0x20010000
0x08003085
而之前我们通过map文件查到的
0x20010000 hal_startup_stack
0x08003084 hal_reset_vsr
那么为什么这两个地址会差1呢，如果我们能合理的解释。那么我们基本上就清晰的了解了CortexM的启动部分了。
查阅CorteM3权威指南
查阅以后我们看到有这样的解释，
在离开复位状态后,CM3 做的第一件事就是读取下列两个 32 位整数的值:
-从地址 0x0000,0000 处取出 MSP 的初始值。
-从地址 0x0000,0004 处取出 PC 的初始值——这个值是复位向量,LSB 必须是 1。然后从这个值所对应的地址处取指。
因为 CM3 使用的是向下生长的满栈,所以 MSP 的初始值必须是堆栈内存的末地址加 1。
举例来说,如果你的堆栈区域在 0x20007C00‐0x20007FFF 之间,那么 MSP 的初始值就必须是0x20008000。
向量表跟随在 MSP 的初始值之后——也就是第 2 个表目。要注意因为 CM3 是在 Thumb态下执行,
所以向量表中的每个数值都必须把 LSB 置 1(也就是奇数) 正是因为这个原因,图 3.18 中使用 0x101 来表达地址 0x100。
当 0x100 处的指令得到执行后,就正式开始了程序的执行。在此之前初始化 MSP 是必需的,因为可能第 1 条指令还没执行就会被 NMI 或是其
它 fault 打断。MSP 初始化好后就已经为它们的服务例程准备好了堆栈。
对于不同的开发工具,需要使用不同的格式来设置 MSP 初值和复位向量——有些则开发工具自行计算。
如果想要获知细节,最快的办法就是参考开发工具提供的一个示例工程。
结论
通过以上的一些论证，我们了解了CortexM的启动特性，以及如何根据ecos的memory配置文件，
保证系统启动的时候设定好stack并且执行到eCos的初始化函数。