c - 在GDB(Eclipse)中使用堆栈跟踪调试Coldfire MCF5235上的未知程序异常

Question

通过第三方库使用CAN控制器时，在我的C应用程序中的某个点（裸机运行，超级用户模式）时，发生了非法指令错误，该错误被ISR捕获；到那时，ISR可用的异常堆栈帧中的程序计数器，错误和返回地址已经为0。当我第一次遇到它时，我能够对堆栈进行一些备份，并看到了这样的堆栈跟踪：

Thread [1] <main> (Suspended : Step)    
    0x0    
    0x41f42200    
    ... 
    timerInterrupt() at timer.c:1,175 0x2432ec    
    0x41902210
    ...
    main() at main.c:1,433 0x211a44

其中0x40000000是此处理器的IPSBAR。

我以已知状态运行了几次该应用程序，该状态可以快速重现此问题，通常在中断/异常跳到0x0之前，最终下降到与堆栈跟踪/保存指令完全相同的状态。通过测试，我注意到跳转只会发生在禁用后重新启用中断后的指令上，或者发生在未屏蔽中断的代码段中。因此，我认为这一定是导致该问题的用户中断，尽管我不确定为什么在掩码中未启用该中断的情况下它会试图调用未设置的处理程序。我不确定100％前面的IPSBAR范围和被调用ISR的地址的含义，但由于该ISR的每次调用都相同，因此我认为我可以用它来指示ISR的来源最后的中断/异常。

因此，我在添加普通处理程序之前再次向中断控制器0上的所有中断向量添加了默认中断处理程序，然后再次运行应用程序-瞧，当触发可疑中断时，默认处理程序中设置的断点被触发（例如，堆栈看起来像这样）：

Thread [1] <main> (Suspended : Step)    
    __DefaultInterrupt() at interrupts.c    
    0x41f42200    
    ...
    timerInterrupt() at timer.c:1,175 0x2432ec    
    0x41902210       
    ...
    main() at main.c:1,433 0x211a44

观察该函数中SWIACK0的值，我看到中断源为100（用户中断36，PIT0中断）。好吧，那已经有一个ISR（上面的堆栈中的timerInterrupt（））。接下来，我检查了保存ISR功能指针的RAM区域，以查看计时器中断处理程序函数指针是否已损坏，但是在设置所有中断处理程序的时间与命中默认处理程序中的断点之间没有任何改变。

我还注意到，如果将CAN控制器的中断处理程序的中断级别设置为7（同一中断处理所有18个FlexCAN中断源），则不会发生此问题。我尚不确定该怎么做，但是这个问题确实指向了CAN库或控制器。

编辑-目前我不确定到底是哪个ISR正在处理中断，但是我已经向最初怀疑的中断源中添加了单独的处理程序，并且它始终是中断源63-根据文档，这是一个未使用的中断，最后一个在中断控制器0上。

编辑2：我想到SWIACK0中的活动中断源实际上是正确的，但是可能还有另一个问题，例如向量基址可能正在被重写。不幸的是，我不确定如何回读它，因为它是只写值。我最初以为PIT0的中断源在该寄存器中，因为默认中断处理程序是从计时器中断处理程序中调用的，但是如果计时器中断不在堆栈中，则还会指出该中断处理程序。参考手册指出，片上调试设备可用于回读控制寄存器，从而回读VBR，但是我看不到调试手册中的任何信息。

为了简短地讲一个漫不经心的故事，我想找出跳转到超空间的源头，或者我可以使用哪些信息来获得它。


IPSBAR范围中的地址被推送的含义是什么
到堆栈上？
由于这些问题似乎与来源完全相关，因此
有一种方法可以使用堆栈中的值（例如，第一个中的0x41f42200
确定该中断/异常的来源
将其推入堆栈？
我要彻底解决这个问题吗？我很高兴
放弃所有这些思路。


感谢您的帮助或见解，当我可以将两个脑细胞摩擦在一起时，将使用更多（简洁）信息进行更新。

Answer 1

解决了这个问题-原来是在勘误表中为CPU处理的。