问题：
该问题由某客户提出，发生在 STM32F407IGT6 器件上。据其工程师讲述：在其产品设计中，使用了IAP+APP 模式的软件架构。IAP 为自行编写的 BOOT 程序，负责系统启动及更新 APP 程序，而 APP则用于处理常规业务。系统启动后，首先运行 IAP 程序，由其完成系统初始化后跳转到 APP。两段程序分别由两个独立的软件工程生成。其中，APP 程序是其于某款 RTOS 构建的。在加入 IAP+APP 模式之前，做了单独的调试，即将其定位到 0x08000000 开始的地址空间直接启动，而不通过 IAP 跳转，证实其可以运行。加入到 IAP+APP 架构中后，这段程序被重新定位到了 0x08004000 开始的地址空间。然而这种情况下 APP 不能正常运行，跳飞掉了。通过打印跟踪，发现从 IAP 到 APP 的跳转可以顺利完成，APP 前几行代码也可以执行，直到执行启动 RTOS 的函数后，不知去向。

: m! G4 `  }$ d调研：
5 n7 T( T( J; V3 x5 j% N7 x' |5 p$ Q检查 APP 软件工程，发现其软件工程是其于 ST 的标准外设驱动库构建的。于是，检查其中的 system_stm32f4xx.c 文件，找到 systemInit()函数，如表（一）所示。

4 {! ~0 J& j; k6 o5 X2 ?
$ z8 q* c; r' v. E( b# U
将其中的行 (1) 由
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET
- l: r# l$ r  E改成：
SCB->VTOR = FLASH_BASE | 0x00004000
重新下载后，RTOS 可以正常运行。
5 U" r; P$ b5 a( ?
' N/ ~8 y- ?6 Q" i7 C
结论：
; e3 `; _% Q5 i  Z9 c; U没有重新定位中断向量表，导致 CPU 依使用 IAP 的中断向量表，进而 APP 的中断无法被正常的处理。通常，RTOS 需要通过中断来进行任务调度，所以，致使其不能正常的运行。
9 \) l7 o* S2 h% [) z. }

处理：
修改软件，重新定位中断向量表到正确的位置。
' g) s5 G7 J* i; p6 w4 T
2 y7 r8 x2 V2 i$ p* G$ c
建议：
Cortex-M3 和 Cortex-M4 的中断向量表是可以在最低 1GB 的地址空间内浮动的，且专门设有一个偏移地址寄存器 VTOR，用于指示中断向量表的位置，如图（一）：
( ?' U8 T' k$ O% l# f. ^
* \4 N( `# W1 Y1 b9 [( P6 f
) C0 h& ?* X& u4 m! {# ~
该寄存器的各个位段的定义如表（二）：
- L3 s+ k1 a! l# J+ m! _
1 ]" p" g! i2 o. p0 h, ~
, C$ q! r1 f& @; Y2 c
3 o9 q5 K9 ^4 g  B- a) Y- XVTOR 的地址为：0xE000ED08，复位值为：0x00000000。所以，复位后 Cortex-M3 或 Cortex-M4 会到地址 0x00000000 取 SP 的取值，而到地址 0x00000004 取 PC 的取值，来启动程序。一般来说，程序启动后要重新装载 VTOR 的取值，使其指向自身的中断向量表，以保证后续程序能够正确的响应各个中断请求。在 Cortex-M3 和 Cortex-M4 的系统中，对于中断向量表的存放位置的对齐边界有一定的要求，可按如下公式计算：
: Z9 k" o6 {7 i8 H8 Y- I
9 i) J) C5 }; u1 Q 其中，N 表示对齐字节数，Size 表示中断向量表的字节数Cortex-M0 没有 VTOR 寄存器，所以它的中断向量表必须放在 0x00000000 地址起始的寻址空间中，而不能浮动。因此，在 Cortex-M0 的系统中，如要更新中断向量表，需将 RAM 映射到 0x00000000 地址，然后将新的中断向量表复制到 0x00000000 地址起始的寻址空间当中。
% p& E% |/ d/ s" c