第4章 System Viewer 实战：中断分析

中断分析，说真的，是VxWorks性能调优里最考验功底的一块。我见过太多系统莫名其妙丢数据、响应慢半拍，最后查来查去，问题都出在中断上。今天咱们就用System Viewer这把手术刀，把中断问题解剖得明明白白。

4.1 中断嵌套检测：别让ISR叠罗汉

中断嵌套，说白了就是一个ISR还没跑完，另一个更高优先级的中断又来了。这在某些场景下是正常的，但嵌套太深，系统就容易出乱子。

我记得有一次，客户说他们的雷达系统偶尔会丢目标。我用System Viewer一抓，好家伙，中断嵌套了5层！低优先级的ISR被高优先级的反复打断，最后连任务切换的时间都没了。

具体操作步骤：

1. 启动System Viewer，加载目标机日志文件
2. 选择View → Interrupt Timeline
3. 观察中断条是否有重叠区域
4. 双击重叠区域，查看具体嵌套深度

4.2 中断响应时间测量：到底慢在哪？

中断响应时间，就是从硬件拉高中断信号，到ISR第一条指令开始执行的时间。这个指标直接决定了系统的实时性。

你想想看，如果响应时间不稳定，那你的系统就是个定时炸弹。我曾经在一个工业控制项目里，发现中断响应时间从5微秒到50微秒乱跳。查了半天，原来是某个驱动在关中断做临界区保护，时间还特别长。

测量方法其实不复杂：

// 在ISR入口和出口打时间戳
void myISR(void)
{
    UINT32 entryTime = tickGet();  // 记录进入时间
    // ... ISR处理逻辑 ...
    UINT32 exitTime = tickGet();   // 记录退出时间
    // 计算差值，就是响应时间 + 执行时间
}

但在System Viewer里，我们有更优雅的方式：

1. 在System Viewer中选中目标中断
2. 右键选择"Show Interrupt Statistics"
3. 查看"Latency"列，这就是响应时间
4. 重点关注最大值和平均值，如果两者差距太大，说明系统不稳定

4.3 ISR性能瓶颈定位：谁在拖后腿？

ISR里最忌讳的就是做耗时操作。但有时候，问题藏得很深。比如一个看起来人畜无害的printf，在ISR里可能就是灾难。

我记得有个网络设备项目，每次收包中断都要处理一个链表。平时没问题，但流量一上来，中断时间就暴涨。用System Viewer的Function Profiler一分析，发现链表遍历占了80%的时间。后来改成哈希表，问题就解决了。

定位瓶颈的步骤：

1. 在System Viewer中打开"ISR Profile"视图
2. 选择要分析的中断向量号
3. 查看每个函数调用的耗时占比
4. 重点关注占比超过10%的函数

优化建议：

• ISR里只做最必要的事，比如读硬件寄存器、清中断标志
• 把耗时操作放到任务里做，用信号量或消息队列通知
• 如果必须用锁，考虑用自旋锁而不是信号量
• 预分配内存，避免在ISR里动态分配

4.4 实战案例：一个中断风暴的排查

最后分享一个真实案例。有个客户说他们的设备每隔几分钟就死机一次。我远程连上System Viewer，发现中断频率从正常的每秒1000次，突然飙升到每秒10万次。这就是典型的中断风暴。

排查过程：

1. 查看Interrupt Timeline，发现是UART中断在狂跳
2. 检查UART驱动，发现中断处理函数里没有清除中断标志
3. 硬件一直认为有中断请求，于是反复触发
4. 加上中断标志清除代码后，问题解决

嗯，有时候问题就这么简单。但如果没有System Viewer，你可能还在那瞎猜是任务优先级的问题呢。