如果你问我：你是不是大神？
我会很确定的说，我不是。
论坛或贴吧发帖求助的时候，都希望能遇见一位大神，拈花一笑，顺手解决自己的问题。现实情况是，哪有那么多"神"？
只是他刚好遇见过你的问题，才能快速的定位、解决。如果是没见过的，那分析起来是很麻烦的。
这里分享一个我之前遇到的案例，用了（摸鱼）半年多时间才找到问题。
当时在一家公司，公司给客户定制的一套产品出现了问题。产品由下位机和上位机组成，下位机主控是一个带M3硬核的FPGA，上位机是电脑端的一个数据显示界面，用QT写的。上位机、M3和FPGA的程序，分别由不同的人负责。
FPGA采集数据，简单处理后放到片内的双端口RAM中，M3定时从双端口RAM中拿数据，做一些计算，然后通过一个网口芯片送到上位机，也就是基于TCP的modbus，先说下时间线。
当前版产品工作正常，然后客户提需求进行升级，更新了上位机和M3的程序。
出现问题：上位机运行一段时间后会卡死，同时下位机M3卡住进而看门狗复位（上位机和下位机哪个先卡住的不好说），导致关键数据丢失。
然后我调入这个项目，要求我解决这个问题。
当时给我的信息是：他们认为上位机没问题，毕竟只是做为主机拿个数据，应该是下位机异常导致的。
我刚调入这个项目，属于新人，谁也惹不起，就按着这个思路去查。
我让上位机的同事协助我测试，发现故障出现的比较频繁，差不多5~10分钟出现一次。我比较诧异，故障出现的太频繁，就问：上一版故障也出现这么频繁？
他回的比较含糊，就说这个网口芯片性能不稳定，网上普遍反应容易重启。
降低了数据通信速率、排查了数据类型，查了一周，没有找到任何问题。
时间久了，客户容易不满意，咋办？
我尝试使用其它方法来避开这个问题。
首先，是关键数据保存。数据基本上以毫秒的速度在更新，这种情况的话存flash不现实。但是，双端口RAM没有用完，还剩了很多可以继续使用。于是我选了一段RAM区域，把M3每次算完的数据更新进来。这样，避开了M3重启丢数据的情况。
然后，是数据的恢复。M3的硬核功能还是比较齐全的，我把相关的例程看了一遍，找到了芯片上电复位的一些寄存器状态（可能和看门狗相关，时间太久记不清了）。即，每次M3上电复位后，会读一下相关寄存器，看是正常的上电启动还是看门狗重启。看门狗重启的话，就去双端口RAM中把之前存的数据读出来，接着用。
通过这种方式，只能是暂时避开了这个问题。但是，究竟是什么原因导致的，依然不知道。
客户不管这些，能用就行。
这种情况一直持续到大约半年后，负责FPGA的同事无意中复现了这个故障。之前能复现，但都是被动的，只能等故障慢慢出现。
但这次复现，是主动的。方法很简单，他无意中双开了上位机...
我瞬间明白了所有问题！
上位机做为modbus主机，和下位机通讯时，偶尔会出现卡顿（原因暂时不明）。这时上位机会认为下位机已经异常复位了，于是没处理当前异常状态，直接重开。在那个时刻，就类似双开，两个主机同时和从机通讯，从机自然忍受不了，真正的重启了。
所以问题由两部分组成：
主机和从机之间的通信卡顿；
卡顿时主机未处理或者未等待，直接重开，导致从机异常。
虽然找到了问题，但是之前那个版本客户已经用习惯了，本着多一事不如少一事的原则，没人提更新的事了...