在对AURIX、TriCore这一类工程进行调试的时候，很多人经常被TASKING中断向量表怎么设置、以及TASKING中断入口跳转异常怎么检查这两个问题卡住。中断的配置，并不是说只要把一个中断服务函数写完就算结束了，它里面还牵扯到很多别的东西。在TASKING软件里面，TriCore的中断向量表，它不是说按照某个具体的硬件名字直接去建立表格的，而是把中断优先级号作为依据来建立入口，如果优先级的号被设成了0，那么这个中断就不会被处理器处理。

　　一、TASKING中断向量表怎么设置

　　在设置TASKING中断向量表的时候，光去看函数的名字是不行的。这个中断到底能不能成功跳到我们想要的入口，其实是被“硬件服务请求优先级”和“向量表入口”是不是一致这件事情决定的。也就是说，当硬件把中断触发了之后，中央处理器是顺着优先级号去寻找对应的向量入口，而不是通过硬件的名字去把函数找出来。

　　1、确认中断入口函数写法

　　在TASKING TriCore的工程代码里面，特殊的属性关键字比如__interrupt和__vector_table，经常会被用来修饰中断函数。其中，中断的优先级是由__interrupt来声明的，而这个中断服务函数到底属于哪一个向量表，则是被__vector_table声明出来的。因为项目的不同，这些写法可能会被IFX_INTERRUPT这样的代码包宏定义包裹起来，但是它的本质，依然是把优先级和向量表的号与中断服务函数绑定在一起。

　　2、确认向量表属于哪个CPU核

　　在有很多个核的芯片里面，每一个核都有可能把自己的中断向量表独立出来。Core0、Core1、Core2它们的向量表是不能放在一起乱用的。比方说，硬件的服务请求明明被配置给到了CPU1，可是中断服务函数却被声明在CPU0的向量表里面，这时候虽然表面上程序能编译通过，但是在中断被触发了以后，程序就会跑到默认的入口里去，甚至还会出现完全没有响应的情况。

　　3、确认LSL里向量表地址放置正确

　　中断向量表在最后，是需要被放置在某个具体的Flash或者RAM地址上面的，这件事情通常会被LSL链接文件来控制。在LSL文件里面，中断向量表的起始地址、对齐的方式，还有具体放在哪个区域，都会被定义清楚。然后启动代码会把BIV寄存器设置到对应的地址上，这样当中断来临的时候，中央处理器才能知道要去哪里把入口取出来。

　　二、TASKING中断入口跳转异常怎么检查

　　中断入口跳转异常这个毛病，往往不是某一个单独的点出了问题。它有可能是因为中断根本就没有被触发，也有可能是因为触发了但是优先级没对上，或者是因为程序跳到了默认的入口里面，甚至还有可能是虽然入口找对了，但是栈、上下文保存区域、上下文保存的过程发生了错误。在排查的时候，必须要顺着整个链路，一步一步地去查看。

　　1、先看中断是否真正触发

　　大家不要在刚开始的时候，就去怀疑是向量表出了错。首先需要去确认的，是硬件的中断条件有没有被满足，比如定时器是不是已经溢出，或者CAN、ADC、UART、PWM这些模块有没有把服务请求产生出来。接着，还要去看看服务请求寄存器里面的SRE是不是被打开了，SRPN是不是一个非0的数，以及TOS是不是确实指向了目标中央处理器。

　　2、再看是否跳到了默认ISR

　　如果中断在触发了之后，程序直接进到了默认的处理函数、默认的中断服务函数或者异常陷阱里面，这不一定是因为硬件配置错了，也有可能是因为中断服务函数没有被正确地放到向量表里面。这里面有几个常见的原因：中断服务函数没有使用正确的宏来声明；优先级号和服务请求寄存器的SRPN没对上；vectabNum和TOS的设置不一致；或者是链接文件没有把对应的向量表段放到有效的地址上面。

　　3、用map文件和反汇编确认入口

　　在对中断跳转异常进行排查的时候，map文件能起到很有用的效果。通过查看map文件，我们可以知道中断向量表段到底被实际放到了哪一个地址上，还有对应的中断服务函数符号有没有被链接进去。如果在map文件里找不到写好的中断服务函数，那就说明这个函数可能被编译器优化掉了，或者是因为没有被引用、声明的方式不对，导致它没有进到正确的段里面。

　　三、TASKING中断配置怎么整理更稳

　　在处理中断问题的时候，最害怕的就是“哪里报了错就去改哪里”。如果只是临时把一个优先级改了，或者把一个向量表号换了，可能在当下中断确实能进去了，但是等到后面要增加新的模块，或者是换芯片型号的时候，问题就又会冒出来。更加稳妥的办法，是把中断的优先级、目标核、向量表、LSL地址还有启动的配置全部都放在一起，进行统一的管理。

　　1、建立中断优先级表

　　在项目里面，最好能单独把一份中断优先级表整理出来，这里面至少要把硬件名称、服务请求节点、SRPN、TOS、目标中央处理器、中断服务函数名和模块的说明包含进去。这样的话，在有新的中断需要被添加的时候，大家就能先去查一查优先级有没有重复、和目标核是不是匹配，而不是在代码里面直接随便瞎填一个数字。

　　2、迁移工程后重点核对启动和链接配置

　　当工程从旧的芯片被迁移到新的芯片，或者从单核的工程被迁移到多核的工程之后，启动文件、LSL文件、BIV的设置、向量表的起始地址，还有每一个核的栈和上下文保存区域配置，都需要被重点去核对。有些时候，中断入口跳转异常并不是因为中断服务函数本身写错了，而是因为在启动的阶段，正确的向量表基地址没有被设置给对应的中央处理器。

　　3、修改后做完整中断验证

　　在把中断的配置修改完了之后，光去看编译是不是通过是不太建议的。至少有三个层面是需要被验证的：第一个是硬件能不能把服务请求标志位置位，第二个是中断能不能顺利进到目标中断服务函数里，第三个是当中断服务函数返回了之后，主程序的流程还能不能正常地继续往下跑。

　　总结

　　想要弄清楚TASKING中断向量表怎么设置，以及TASKING中断入口跳转异常怎么检查，关键的办法就是要把中断服务函数的声明、SRPN、TOS、目标中央处理器、BIV、LSL还有启动代码绑在同一条链路上来进行核对。在排查的时候，硬件是不是真的把中断触发了需要先被查看，接着再去看程序有没有进到默认的中断服务函数里，最后还要结合map文件、BIV寄存器以及反汇编把跳转的位置确认清楚。如果能按照这个路子处理下来，中断的问题就不会只停留在“能不能进函数”的表面层次上了，而是能把配置链路里具体的断点给真正找出来。