- #define FLASH_BASE ((uint32_t)0x08000000) /*!< FLASH base address in the alias region */
- #define VECT_TAB_OFFSET 0x0 /*!< Vector Table base offset field. This value must be a multiple of 0x200. */
- #define SCB ((SCB_Type *) SCB_BASE) /* !< SCB configuration struct */
- void SystemInit (void)
- {
- /****************此处省略部分代码****************/
- #ifdef VECT_TAB_SRAM
- SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM. */
- #else
- SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH. */
- #endif
- }
其中 SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; 这一行代码就是把异常向量表基地址更改到了0x08000000的地址中去了。
补充：我曾自己写过简单的启动文件测试，并没有去调用SystemInit函数，自己也没有在其他地方对向量表的基地址更改到0x08000000的地址中去，但是当CPU检查到有中断发生时，还是可以跳转到正确的中断服务函数的入口地址处。为什么会这样？我查阅了下相关的资料，了解到当APM32从Flash启动时，实际上会把Flash的那段存储空间0x08000000 ~ 0x0807FFFF映射到0x00000000 ~ 0x0007FFFF这一段地址的存储空间，也就是说当CPU从Flash启动时，CPU从0地址处开始执行指令和从0x08000000地址处开始执行指令是一样的。所以，这个时候我没有去更改异常向量表的基地址，CPU仍然可以跳转到正确的中断服务程序。
2.3 保存现场
2.3.1 概念引入
我们在Keil里面写一段非常简单的代码，实现 a = a + b; 这个式子。当然我们并不是要去关心这个式子本身，而是利用Keil的仿真功能，去查看一下CPU执行这个式子后，其内部寄存器的变化。仿真截图如下：
从上面这个仿真的汇编代码可以看出，CPU要完成 a = a + b; 的运算，实际上是先去读取a, b的内存所保存的数据到内部寄存器r0, r1中，然后再执行r0 = r0 + r1的运算，最后把r0的值写回到内存a中，这样才完成了一次a = a + b; 的运算。另外，可以观察到CPU在运行程序的过程中，它内部的r0 - r15，还有程序状态寄存器xPSR的值，都是在不断的变化中的。
那么问题来了，假设CPU在运行这 a = a + b; 这个式子的中途，程序运行过程中断打断了。要想这个式子可以正确运行，那么就要确保中断前CPU的这几个寄存器的值以及中断返回后这些寄存器的值都要保持不变，还有保存在内存空间a, b的值也不会被改变。这样运行这个式子得到的最终结果才是正确的。
对于保持a, b内存的值不变，这个好办，中断程序中不要去改写a, b的值即可。但是我们如何保持中断前后CPU内部寄存器的值不被改变呢？因为中断程序的运行肯定也是需要用到CPU内部的寄存器的，所以必须得有一种机制去保持中断前后CPU内部寄存器的值不被改变。也就是说，所谓的现场，实际上就是CPU运行到某一时刻时，CPU内部寄存器的值。
那么如何保存现场和恢复现场呢？这就需要用到栈。CPU在跳转到异常/中断程序前，就需要把这些不希望被中断程序所改变的寄存器的值保存到栈中，这就是保存现场。在异常/中断处理完之后，从栈中恢复这些寄存器的值，这就是恢复现场。
2.3.2 保存哪些寄存器的值
上面说了，所谓保存现场就是保存CPU内部一些寄存器的值到栈中。CPU内部常用的寄存器有 r0 ~ r15，再加上程序状态寄存器，一共16个（当然其他模式下可能还有对应的其他寄存器）。下图就是APM32F103内部寄存器示例（M3内核不具有浮点运算单元，这里不讨论浮点运算单元的寄存器了）：
当发生异常/中断时，CPU跳转之前，就需要把这些寄存器的值保存到栈中，那么我们需要把CPU的这16个寄存器都保存到栈中吗？很显然是不需要的。
ARM公司推出了一个ATPCS标准，即ARM-THUMB procedure call standard（ARM-Thumb过程调用标准）。在这份标准里面，都规定了这16个寄存器的使用规则，如下表所示：
比如函数A调用函数B，那么函数A就是调用者，函数B就是被调用者。那么根据这份ATPCS规则，函数A在调用函数B之前，函数A就应该要保存r0-r3, r12, lr, psr这几个调用者要保存的寄存器；而对于r4-r11这几个寄存器，调用函数B的前后，函数B本身会保证调用前后这些寄存器的值保持不变。
那么，如果函数B是中断服务函数，因为函数B本身会保证r4-r11的值不会被改变，所以保存现场也就是保存r0-r3, r12, lr, psr这几个寄存器的值即可。
2.3.3 APM32如何保存现场
我们已经知道了什么是现场，保存现场要保存哪些寄存器的值了。那么对于APM32来说，是如何保存这些寄存器的值到栈中的呢？
非常幸运的是，APM32保存现场的工作是CPU的硬件自动帮我们完成的（我们不要想当然的认为所有架构的硬件都会帮我们完成这部分工作，对于Cortex-A7架构来说就不是硬件帮我们完成的），我们不需要自己写代码去把中断前需要保存的寄存器的值存放到栈中。具体过程如下图所示：
2.4 恢复现场
恢复现场就是指CPU执行完异常/中断服务函数后，返回到LR寄存器所指示的地址处（就是中断前的下一条指令的地址），并且把保存在栈中寄存器的值恢复到寄存器中去。
对于如何返回到中断前下一条指令的地址，其实很容易就可以实现，只要我们把下一条指令的地址存放到LR寄存器即可，CPU返回的话就是把LR寄存器的值赋值给PC程序计数器，这样就可以返回到了中断前下一条指令中继续运行程序了。但是如果这样做的话，硬件帮我们保存在栈中的寄存器的值，返回去是怎么恢复那些寄存器的值？
对于这个问题，APM32帮我们实现了一套机制。CPU进入异常/中断服务程序时，LR寄存器保存的并不是中断前下一条指令的地址，而是会保存一个特殊的数值，被称为EXC_RETURN。对于EXC_RETURN位域的定义和具体的数值含义，可以查看《ARM Crotex-M3与Cortex-M4权威指南》一书中第八章的描述。这里截图如下作为参考：
所以，当异常/中断返回时，LR寄存器赋值给PC的值是一个被称为EXC_RETURN的值，而一旦CPU识别到PC的值等于EXC_RETURN的话，那么就会触发异常/中断返回机制，这个机制会帮我们把保存在栈中r0-r3, r12, lr, psr的寄存器的值恢复回去。
楼主
