在芯片工程的移植过程中，技术人员经常会遇到一些比较棘手的问题，比如IAR启动文件到底该怎么去配置，以及IAR启动文件和中断向量表之间又是怎么产生对应关系的。启动文件在整个系统中起到了很关键的作用，芯片在复位之后先去执行什么代码，栈指针需要从哪个地方去获取，这些全都是由启动文件来决定的。

　　一、IAR启动文件怎么配置

　　在对IAR启动文件进行配置的时候，开发者首先不能只去看文件名是不是长得很像,启动文件最好是直接从相同型号芯片的官方SDK或者例程里面去获取。

　　1、需要去确认当前工程里正在使用的启动文件

　　当开发者把工程树打开了之后，首先要在里面找到名称是startup_xxx.s或者cstartup_xxx.s之类的汇编文件。如果发现工程目录里面同时存在好几个启动文件，那么开发者就必须去确认一下，一定要保证只有目标芯片对应的那一个启动文件参与了编译。如果一些旧芯片的启动文件还被遗留在工程里面，这就很容易导致系统产生重复的符号，或者导致向量表出现错误，甚至还会让中断函数的名称跟头文件对不上。

　　2、需要去检查启动文件跟芯片的型号是否能够匹配

　　在启动文件里面，一般都会包含向量表、Reset_Handler、默认的中断处理函数，还有堆栈符号的引用等很多内容。在进行工程移植的时候，开发者应该优先去芯片厂商的SDK、BSP包，或者评估板的IAR官方例程里面，把对应型号的启动文件复制过来使用。=

　　3、需要去核对链接脚本里面的具体栈地址

　　通常来说，启动文件的第一项内容都会去引用栈顶的符号，但是这个实际的地址往往是来自于.icf链接文件的。开发者需要点击进入【Project】→【Options】→【Linker】→【Config】这个路径，去确认一下当前的.icf文件里面，关于RAM的范围、栈的大小，还有栈顶符号是不是都是正确的。

如果芯片的RAM容量已经发生改变了，但是启动文件却还在引用旧工程那边的栈符号，那么程序很有可能在刚刚复位的时候就直接进入到异常状态了。

　　二、IAR启动文件和中断向量表怎么对应

　　关于启动文件和中断向量表之间的特殊关系，其实可以把它用很简单的话来理解：启动文件在里面其实就是定义了一张由很多入口地址组合起来的表，当芯片遇到了复位、异常，或者是外设触发中断的时候，系统就会按照原先固定好的顺序，去这张表里面寻找对应的处理函数。

　　1、首先应该去查看向量表的前面几项内容

　　向量表的开头部分，一般放的都是初始的栈顶、Reset_Handler、NMI_Handler，还有HardFault_Handler这些内容。如果系统在复位之后，程序连main函数都进不去，那么开发者首先就得去观察一下栈顶的地址、Reset_Handler的地址，还有Flash的起始地址，看看它们之间是不是一致的。特别是当工程里面存在Bootloader偏移的时候，应用程序的向量表就不会再待在默认的Flash起始地址上了，这个时候启动文件、链接脚本，以及负责跳转的代码，这三者必须一起进行修改才行。

　　2、需要按照IRQ的顺序去认真核对外设中断

　　外设中断的入口绝对不是按照函数名字随便乱排的，它们必须严格地按照芯片手册，还有CMSIS头文件里面写好的IRQn顺序来依次排列。

像那些定时器、串口、DMA，以及ADC之类的中断，如果它们在启动文件里面的顺序被弄错了，虽然系统表面上打开的是串口中断，但是实际运行的时候，程序可能会直接跳转到其他的默认处理函数里面去。当遇到“中断已经打开了但是就是进不去”这种头疼的情况时，开发者不要只顾着去看NVIC的配置，也必须要去好好核对一下向量表的位置。

　　3、需要去确认中断函数的名称是不是保持一致

　　在启动文件里面，那些经常能看到的中断处理函数一般都是以弱定义的形式存在的，如果用户在自己的代码里面写了一个名字一模一样的函数，那么系统在链接的时候，就会用用户的函数去覆盖掉原先默认的处理函数。

在排查这个问题的时候，开发者可以去.map文件里面搜索一下对应Handler的名称，看看最终链接成功的到底是用户自己写的函数，还是系统默认的函数。

　　三、当启动文件配置出现异常的时候该怎么去排查

　　有时候，启动文件引起的问题并不会在编译阶段表现为错误，它们往往要等到程序跑起来之才暴露出问题。比较多见的故障现象包括：系统复位了之后进不去main函数；程序莫名其妙地进入到HardFault里面；中断完全没有响应；Bootloader无法成功跳转；或者在调试的时候发现PC指针跑到了一些很奇怪的异常地址上去。在对这些问题进行排查的时候，开发者一定要把启动文件、向量表、链接脚本，还有调试下载的配置全部结合在一起，把它们放在一起去观察。

　　1、应该先利用最小工程来验证整个启动链路

　　开发者可以先把多余的东西拿掉，只保留启动文件、system_xxx.c、主函数，还有一个用来让GPIO翻转或者让串口输出的简单功能。先去确认一下程序是不是能够正常地复位、能不能成功地进入main函数、能不能正常地在循环里面跑起来，等到这些都确认好了之后，再把外设和中断一步一步地加进去。如果连最小工程都跑不正常，那么开发者先不要急着去怀疑业务代码有问题，应该优先去检查向量表的地址、栈的地址、链接脚本，以及启动文件的型号。

　　2、需要对照着.map文件去检查符号的情况

　　在程序重新编译过之后，开发者需要把.map文件打开，去里面仔细查看Reset_Handler、__vector_table、各个IRQHandler，以及跟stack相关的符号具体都被安排在什么位置。因为在IAR的整个构建链路里面，会同时涉及到编译器、汇编器，还有ILINK链接器，所以最终符号的落脚点必须得以链接出来的结果为准，开发者绝对不能只看源文件里面是怎么写的。

　　3、在进行Bootloader工程设计时必须对向量表进行重定位

　　如果应用程序不是从Flash默认的起始地址开始运行的，那么Bootloader在跳转到应用程序之前，就必须先去设置好应用栈的指针，然后再跳转到应用向量表里面的复位入口处。在应用程序启动了之后，开发者也需要去确认一下VTOR是不是已经指向了正确的向量表地址，否则的话，虽然main函数能够进得去，但是后面所有的中断可能都会表现出异常。这个问题在在线升级、双分区启动，以及带有参数区的工程项目里面是非常容易遇到的。

　　结论

　　想要配置好IAR的启动文件，最关键的一点，就是要让startup文件、芯片的型号、CMSIS头文件、.icf链接脚本，还有调试下载的地址这几者之间保持完全一致。而IAR启动文件和中断向量表之间的对应关系，它的本质其实就是让向量表去按照一个固定好了的顺序，把栈顶、复位入口、异常入口，还有外设中断入口给保存起来。只要把这几个地方全部都对齐了，那么绝大多数的启动和中断问题，基本上都能够比较快地被找出来。