[参考译文] LMK04610：RESETN 释放后无法写入寄存器

尊敬的 Dilan：

如果帖子格式设置不正确、我们深表歉意-在新网站上进行移动发布会导致难以准确评估/更正文本大小。

您如何确认寄存器编程？ 正在检查特定的器件行为？ 读回寄存器？

请注意、LMK04610需要在对所有其他寄存器进行编程后大约25-30ms 对 DEV_STARTUP=1进行编程。

此致、

Derek Payne

尊敬的 Derek：

感谢您的快速回复。

为了提供更多详细信息、LMK 编程是在 FPGA 器件加电后完成的(因此非常快)。 然后、我们将通过读回寄存器值(通过同一 FPGA)来检查寄存器配置。 该读数在 LMK 编程几秒钟后完成。 我们观察到所有寄存器保持其默认值、并且我们预期在一个 LMK 输出上看到的输出时钟未生成。

当 RESETN 从未置位时、我们观察到寄存器配置正确、输出时钟正确生成。

我可以确认 DEV_STARTUP 配置在两种情况下都是在编程序列结束时完成的。

此致、

迪尔安·艾伯特

尊敬的 Dilan：

我可以获得您的寄存器编程副本吗？ 我想确认编程序列和值可以在我们的实验中复制。

此致、

Derek Payne

尊敬的 Derek：

当然、请在 下面找到我们使用的寄存器编程序列的副本。

e2e.ti.com/.../lmk04610_5F00_prog_5F00_seq.txt

如果您对此有任何疑问、请不要犹豫。

此致、

迪尔安·艾伯特

尊敬的 Dilan：

今天我们的实验室 EVM 工作时遇到了一些问题、但 我想我解决了这个问题。 很抱歉耽误了时间、我明天将详细介绍这一点。

此致、

Derek Payne

Dilan、

我在 EVM 上加载了您的编程、看起来一切正常、并且我具有回读功能(即使 在 RESETN 切换后也是如此)。 这指向 SPI 通信问题。 我建议您仔细检查 SPI 时序是否符合数据表 SPI 时序图。  时序图的一个不明显的结果是 ，SCL* 变为低电平之前，SCL 引脚应该为低电平。

请注意、我看到您已将其中一个输出配置为 SYSREF。 请注意 、除非 PLL2预分频器的输出上存在时钟、这意味着需要锁定 PLL2 (无论是否使用 PLL2)、否则在分配模式下不可能触发 SYSREF 脉冲。

此致、

Derek Payne

尊敬的 Derek：

感谢你的答复。

我已经检查了与 SPI 接口相关的时序、以确保我们符合 LMK04610数据表。  如果您可以在侧面检查、我在下面插入了与 LMK 的 SPI 通信的时间图。

对我来说、一切都应该很好：

• RESETN 在 SPI 通信前被切换(1 -> 0 -> 1)。 RESETN 低电平脉宽持续时间 超过100ns
• 在 SCSN 设置为低电平之前、SCL 保持低电平
•  CS*下降沿与 SCL 上升沿之间的延迟约为30ns
• SPI 时钟频率约为15MHz

事实是、当 RESETN 按照时间图中所示进行切换时、LMK SPI 寄存器不会更改、并且即使按照编程顺序也会保留其默认值。 但是、如果我们 在启动时将 RESETN 绑定到"1"(RESETN 从未置位)、同一 SPI 序列就能完美工作。

 令人放心的一点是、该序列似乎适用于您的电路板。 您能否最终分享在 SPI 接口上实施的 SPI 时序，以了解我是否可以使其与之配合使用？

对于 SYSREF、是的、您说得对、我们仍在使用 PLL2来处理序列、以便能够根据需要生成 SYSREF 信号。 感谢您的观看。

此致、

迪尔安·艾伯特

Dilan、您好！

感谢您提供的详细信息、我们将在我们的一侧对此进行探讨。  我知道它不是15MHz…… 可能更接近1MHz。

73、
Timothy

Dilan、

正如 Timothy 所建议的、我们自己的 SPI 的运行频率要接近1MHz。 尽管如此、我认为 SPI 频率不应该是问题：您生成的复位脉冲 似乎有选择性地阻止器件通信。

仅出于测试目的、您是否在 RESETN 引脚上尝试过其他持续时间？ 因为我要手动切换 RESETN 线路、所以复位脉冲宽度接近300ms、RESETN 0 -> 1与 SPI 编程开始之间的延迟更像是1s。。。 您可以尝试单独改变这两个参数、以查看它们是否起作用。

USB2ANY 还会在每次 SPI 写入之间引入10-25ms 的编程延迟...  这更难进行测试、但如果其他选项用尽、可能值得探索。 我将在大容量 SPI 编程和器件启动位编程之间插入一些延迟、以此启动调查 ARM。。

此致、

Derek Payne

尊敬的 Derek：

好的、感谢您提供的这些信息、根据您的建议、我将 对 RESETN 脉宽持续时间以及 RESETN 失效和 SPI 编程开始之间的延迟进行一些实验。 我会让您了解我的结果。

就个人而言、我认为问题不是 SPI 写入之间的持续时间问题、因为同一序列似乎正常工作、但如果没有 RESETN =>最后我将尝试此测试

此致、

迪尔安·艾伯特

好的、请继续发帖。

73、
Timothy

Derek、Timothy、您好

我可以进行一些测试、我可以为您提供一些结果。 下面是测试列表：

• 测试 NB 1：启动时、RESETN 在300ms 内设置为"1"、然后 RESETN 在300ms 内设置为"0"、然后 RESETN 设置回"1"、 SPI 编程在 RESETN 失效后大约150ns 开始。 结果是未生成预期的输出时钟=>该序列不起作用。
• 测试 NB 2： 启动时、 RESETN 在150ns 期间设置为"1"、然后在150ns 期间将 RESETN 设置为"0"、然后 RESETN 设置回"1"、 SPI 编程在 RESETN 失效后大约300ms 开始。  结果是生成了预期的输出时钟=>这个序列 看起来有效。

根据这些测试、我觉得在 RESETN 释放和 SPI 编程开始之间有必要有一个最小延迟、这样 PLL 可以接受 SPI 写入。

您对这些测试有何看法？ 请告诉我、您是否需要我使用不同的参数进行更多测试。

此致、

迪尔安·艾伯特

Dilan、

您的结果对我来说很有意义。 我们之前的指导(RESETN 被置为1后、可能会立即进行 SPI 编程)似乎不正确。 由于数据表中的任何位置都未捕获此信息、因此我认为我们应该 确定 RESETN 到 SPI 时序的实际值并将其包含在下一个数据表修订版中、这对每个人都很有帮助。 我将尝试与能够查看器件数字实施的人员确定最小延迟、并让您知道我发现的内容。

此致、

Derek Payne

感谢您的回复 Derek、我将等待您的调查和结果来更新我的 SPI 序列。

此致、

迪尔安·艾伯特

尊敬的 Derek：

感谢您的详细回答。

我测试了您建议的值200ms、SPI 编程仍在工作。 因此、我将为我的设计保留该值。 请告诉我、在进行更多调查后、是否需要调整该值(以 更大的值)。 当然，我将监控数据表的下一个修订版本，以检查是否需要更新此延迟。

再次感谢您的支持。

此致、

迪尔安·艾伯特