标签：今天 其他 命令 事件 异常 时钟 模式 load 进入
从今天开始，记录本人在设计中留下的隐藏bug，时常翻阅，谨记于心。
1. 项目中有一些保护事件，其中一个保护事件的级别最高。当该事件发生时，系统状态机进入保护模式，直到事件消失，再回到其他状态。
然而，因为一些其他原因，在该最高级别的事件发生时，引起了power on 复位，致使内部所有trimming值复位成0。如果要恢复这些trimming值，
就必须重新进行OTP（efuse）load，而正常的OTP load过程需要状态机从IDLE进入。虽然power on复位产生了，状态机也复位成IDLE了，但是
由于该事件的最高优先级性，致使当power on 复位释放后，状态机又立即进入了保护模式，跳过了OTP load状态。最终导致，即使该事件消失，
power on复位释放了，电路也不能正常工作。
解法：考虑在该事件释放时，触发一次OTP load，或者修改系统状态机。
2. 设计中为了防止异常状况出现，增加了一个软复位功能，也就是通过通讯接口（I2C、SPI或者UART等）写入命令，来触发一次复位。
设计中的做法是，当通讯接口写入命令后，一个中间变量有效，再用内部时钟打三拍进行同步处理，用第二、第三拍做一个上升沿pulse，将这个pulse取反，并入
全局复位rst_n，组成了新的全局复位rst_n。按道理，这样做是没有问题的。但实际上忽略了一个问题。因为全局复位rst_n，既用于通讯接口电路，
也用于上述三拍同步电路，所以当进行软复位时，既复位了其他电路，也把同步电路复位了，这会造成综合后的电路，那个pulse引起的复位时间（即取反后的低
电平维持时间）很短，有可能不能产生有效的复位。
解法：更换上述三拍同步电路的复位源。
标签：今天 其他 命令 事件 异常 时钟 模式 load 进入
原文地址：https://www.cnblogs.com/hxing/p/14423948.html
