通宵火车，还是硬座，闲的。回看之前总结的两篇修板子的历程：
第一次修板子的历程
又一次修板子的历程

又看到个“将PWM信号1:4扇出”的帖子，似乎是说的时钟分发芯片。于是一首BGM在本青脑海中响起：
那一句话是你离开的玩笑话
搁在我心里 灰尘堆成了塔
你就这样的拨开了它
在信箱前我依旧是那个木偶
线等着你来拉

朗朗饿狗，本青还有一头乌黑亮丽头发的时候。某天，驱动扔过来一块板子：“上电启动正常，但软件重启起不来。”
就像每当发生危机时，美帝总统会问：”最近的航母在哪里？“本青也会问：”看门狗呢？“
“每30s的硬件看门狗复位， 加上每30分钟跟上级设备不通的高层软件复位，过了一个晚上了，都没复位拉起来。你那狗早就变成狗肉下肚了！”

排查过程：此处省略x千字。
根本原因：时钟分发芯片输入输出之间的延迟大，导致CPU读挂在CPLD上的boot失败。
feature 1：板子上软件用的时钟，来源于一片挂CPU上的晶振。CPU再把该时钟从CPU时钟输出管脚输出给一片时钟分发芯片，分别分配给CPLD、FPGA、DSP等。
feature 2：时钟分发芯片的输入端收到第一个时钟脉冲，到输出端输出第一个时钟脉冲，存在一个时间延迟t0，只跟该时钟分发芯片有关。
feature 3：复位释放以后，CPU以外挂晶振为时钟运行，从开始运行读第一行rom code代码，到发出CS去读boot，所需的时间是t1，可以算是固定值。
feature 4：CPLD收到CPU送给的复位以后，将复位信号拉低/高，分别发给boot、FPGA、DSP等，同时用时钟分发芯片给的时钟来完成复位原因、复位次数等状态机的运行，再释放被拉低/高的复位信号，所需时间t2，也能算是固定值。
bug过程：
过程1：软件通过CPU的IO发出复位指令给CPLD，CPLD送回复位给CPU，CPU复位。同时CPU输出的时钟也会关断。复位释放以后，CPU打出CS去读boot，所需的时间t1基本固定。
过程2：异常板子上的时钟分发芯片的输入输出延迟t0，比正常板子的要大了几十倍（从正常的十几微妙级别，成了几百微秒级）。CPLD内部状态机跑完，花费时间t0+t2后，再把CPLD控制的复位释放掉。这些复位就包括boot的复位。
过程3：CPU按t1的时间，打出CS去读boot的内容。但此时t0变大，导致t0+t2变大，CPLD给boot的复位还没释放。CPU读boot失败，死掉。看门狗正常运行，每隔30s后送出的复位，重复过程1到3，还是起不来。软件复位也是外甥打灯笼。

上面“软件重启起不来”的过程说得通了，那“上电启动正常”就说不通了。还得继续排查。
排查过程：此处省略x千字。
原因：启动的时候，因为看门狗送出的看门狗复位+时钟分发芯片的延迟增加的原因，CPLD就没有收到时钟，也就没有把CPLD的上电复位送出。CPU按照t1的时间送出CS去读boot，此时boot仅靠自己电源管脚上并联的电容假装一个很短上电复位，CPLD的复位并没有拉着boot，自然顺利起来了。

解问题：看时钟分发芯片手册，上面只有锁定的时间，且是毫秒级别的，没去法找厂家的岔子。拆下时钟分发芯片寄给厂家，厂家在自己设备上测试不能复现现象。作罢。
解bug：换一颗时钟分发芯片，解决。
--
FROM 116.162.0.*