这是对几个月前发布的关于写入 SN74V293的数据与从中读取的数据之间不匹配的问题的后续跟进。
希望 此处的链接 将正确重定向到它。
在本应用中、 某些时间 FIFO 读取时钟由 STM32F427的 MCO1输出生成。
在此应用中、MCO1连接到25MHz 时钟源。
事实证明、当被选作引脚输出功能时、MCO1的表现非常糟糕(但这不是主要问题：我稍后就会这样做)。 当引脚从 GPIO 更改为 MCO1时、MCO1的显示方式如下(蓝色迹线、几个示例)：
在此应用程序中、当选择 MCO1作为时钟时、REN (FIFO 读取启用)不会生效、如果 PAE 是同步更新、则需要此参数。
之后、REN 生效以启用读取时钟来更新 FIFO 输出端的数据。
由于 REN 一直被代码置为有效、REN 和 RCLK 之间的关系未被定义、并且、虽然建立时间和保持时间非常宽容、但在某些情况下、它们的违例导致了 FIFO 的错误行为。
在我的500MHz 带宽 MSO 上、有一些 REN (绿色迹线、标记为 DB8)和 RCLK 在随后运行正确时的捕获：
这是后续操作不正确时的捕获：
因此、在随后失败的操作之前的跟踪实际上似乎更有可能满足设置和保持要求。
我已修改代码、从而使 RCLK 来自表现正常的源。 此外、时钟会在 REN 置位之前停止、然后重新启动、从而确保允许大量的设置时间。
进行这些修改后、不会发生中断的输出。
惊喜(对我来说！) 违反 REN 和 RCLK 时序会导致 FIFO 的内部读取和写入寄存器持续失效。 似乎只是通过发出复位来修复此故障。
可能有点愚蠢、我以前不担心 REN 和 RCLK 之间的设置和保持时序、因为我认为结果会是错过的读取事件。 应用中最重要的东西。
回到原来的帖子、Emrys 在提出计时问题导致存储不正确的数据时几乎是正确的。 事实上、单个不正确的时序违例会导致错误地检索所有后续数据。