[参考译文] DAC8760：与 CRC 进行菊花链通信

admin

Other Parts Discussed in Thread: DAC8760

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

器件型号：DAC8760

在所有器件中以菊花链配置使用八个 DAC8760器件实施 CRC 后、我们仍然会遇到长期稳定性问题。我们的菊花链似乎在不可预测的时间间隔(从5天到30天)间歇性"断裂"、从而导致所有后续 DAC 不起作用、直到进行下电上电和重新初始化。

我们没有启用看门狗功能、而且也没有主动监控 ALARM 引脚或相应的寄存器。

请您澄清以下几点：

如果看门狗功能由上述位模式错误在一个或多个 DAC 上随机启用、这是否会导致 mA 输出行为发生任何变化或使其停止？
在触发警报的情况下、无论其原因如何、这是否会导致 mA 输出行为发生任何变化或停止？
是否也可以通过一个特定的位模式在不拉锁存器的情况下禁用 CRC 功能？
no OP 命令到底可以对 CRC 计算执行什么？完整的菊花链数据传输(在我们的设置中包含8倍32字节)是否可以用于复位"SPI 计数器"的相同目的、无论这是什么意思？

紧急援助势在必行、因为我们仍不知道部署在敏感区域的器件数量可能会突然停止更新其 mA 输出。我们对这些事件的根本原因感到困惑。

特别令人不安的是，这标志着我们不得不进行数周调试的第二次机会。在上一实例中、我们十分幸运地发现了 CRC 错误、随后精心分发的固件更新使我们在全球部署的所有器件的 CRC 通信变得更加紧密。

感谢您对此事的及时关注。

0 admin 2 年多前

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

关于这一问题，请允许我为这篇文章的其他读者提供一些背景。大约两年前、我们对数据表进行了更改、删除了推荐使用的菊花链模式。

正如我们在之前版本的数据表(在8.3.9.1和8.3.10.1节中)中提到的、可能存在会错误地导致看门狗计时器或 CRC 在 LATCH 引脚的上升沿情况下启用的特定位模式。这些位模式显示在之前数据表修订版本的表4和表6中：

此外、我们担心使用菊花链时、通过向共享 SPI 的多种类型的器件发送多个命令的过程可能会看到这种数字模式。这会意外地启用 CRC 或设置看门狗计时器。

最后、我们选择从数据表中删除菊花链。将器件与能够处理独立 SPI 集的控制器结合使用会更容易、或者使用具有单独/CS 选择和门控 SCLK 的并行 SPI 线路。数据表中的变化并不是器件变化引起的。该器件自2013年推出以来保持不变。对于使用菊花链的现有客户、他们可以继续使用菊花链。

对于您的问题、下面提供了一些答案。

看门狗功能本身不会触发输出电流的额外变化(或来自器件的电流)。在数字部分中、看门狗本身作为来自器件时钟的定时器实现、用于等待数字通信。
触发警报后、会设置与器件输出对应的状态寄存器故障标志。 DAC 输出不变。唯一的变化是/alarm 引脚被拉低以响应警报。这将增加器件电流、因为/ALARM 引脚需要一个上拉电阻器。
我认为不能通过类似的方法禁用 CRC。基于我对这个问题的理解、意外启用 CRC 会使器件进入一种模式、在该模式下、无法通过写入配置寄存器来启用或禁用 CRC。此外、ALARM 引脚和状态寄存器不指示 CRC 警报条件、并且不会忽略具有错误或缺失 CRC 位的帧。我将与一位数字设计人员核实以便确认这一点。
我不确定我是否理解这个问题。这是指发送 NOOP 命令以重置器件中的 SPI 时钟和帧(在数据表第33页末尾)吗？对于 NOOP、这用于在 SCLK 线路上的任何瞬态被解释为 SCLK 周期时对齐 SPI 帧。我不知道为什么要将其插入到数据表中、但我认为这是绝对必要的。帧应在正确的 SPI 命令后对齐。

我已请求 E2E 友谊、这样我们可以互相发送消息。我认为这种方法比通过 E2E 发布更快速地传达此信息。

约瑟夫·吴

数据转换器（参考译文帖）(Read Only)