This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] DAC8750:同时发生报警置位和数据发送的事件

Guru**** 2442090 points
Other Parts Discussed in Thread: DAC8750

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

https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1353668/dac8750-the-event-occurring-both-alarm-set-and-data-send-at-the-same-time

器件型号:DAC8750

您好!

我的客户已 将 AD5420替换为 DAC8750、因为它们是 P2P 兼容的、但在警报设定和数据发送同时发生的情况下、它似乎将数据写入意外的寄存器。  AD5420似乎使该事件中的数据无效、但您能否告诉我在该 事件中对 DAC8750的预期行为?  我的客户应该如何应对该事件?  我查看了数据表、应用手册和 E2E、但没能找到相关信息。

此致、

川崎义和

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

    尊敬的 Yoshikazu-San:

    客户是否能够更具体地了解该情况?

    是否会触发警报并在写入寄存器的同时变为低电平?
    客户能否提供尝试的寄存器写入和发生的错误写入?

    谢谢。
    卢卡斯

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

    卢卡斯-圣、

    非常感谢您的快速回复。  问题似乎是这样出现的。

    警报变为低电平、同时发送数据

    ->发生意外的寄存器写入

    -> DAC8750表现出意外行为  

    我问这些问题、但您还有其他想要检查的问题吗?

    1. 报警低电平和数据发送之间需要多长时间的重叠时间?

      (报警变为低电平之前/之后是否必须完全相同或数据仅发送几个用户?)

    2.发生该问题时 DAC8750的行为如何?

    3.哪些寄存器会受到此问题的影响?  它们始终是一样的吗?

    4.意外写入了哪些数据?

    5.问题发生之前/之后、您能否提供寄存器转储?

    此致、

    川崎义和

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

    你好,卢卡斯-圣,

    我可以获得问题的答案、如下所示。  如果您需要更多信息、请告诉我吗?

    1.  报警低电平和数据发送之间需要多长时间的重叠时间?

      (报警变为低电平之前/之后是否必须完全相同或数据仅发送几个用户?)

    (AN)他们不知道这一点。  实际上无法检查重叠时间、因为它们的系统上没有用于报警引脚的 TP。

    2.发生该问题时 DAC8750的行为如何?

    (ANS)当问题发生时、IOUT 有3种行为:不稳定(上/下)零点、增益下降或两者兼有。  该问题可能仅在30-60分钟内发生、但通常在3-5小时内发生。  通信周期为每秒50次。  正常情况下、应该有24个时钟来访问寄存器、 如下方所示、但如果问题发生、则时钟会在中断触发时在中间停止工作、如下方所示。

    3.哪些寄存器会受到此问题的影响?  它们始终是一样的吗?

    (AN)从上述#2中,它们 仅监视本应意外写入数据的配置寄存器、增益寄存器和零寄存器。  其系统上的主机仅访问控制寄存器和数据寄存器。  这并不总是相同的、而是随机的、例如仅将数据写入 CONFIG、CONFIG 和 GAIN 等。

    4.意外写入了哪些数据?

    (AN)其系统仅使用控制寄存器和数据寄存器、因此在添加监测配置/增益/零寄存器之前、他们不确定数据是否总是相同、但现在是相同的。  不过、量产版本(不带监控配置/增益/零寄存器)并不总是在 IOUT 引脚上显示相同的行为、因此他们假设它不会是相同的。

    5.问题发生之前/之后、您能否提供寄存器转储?

    (AN)这些是问题发生后转储的数据示例。  其系统上的预期值全部为0。

    配置:21808000

    增益:21808000

    零:1487.70

    此致、

    川崎义和

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

    尊敬的 Yoshikazu-San:

    客户能否提供其电路原理图?

    他们是否知道引起警报的原因? 它们能否回读状态寄存器以查看触发了什么故障?

    通信问题发生后、我还对它们寄存器的值感到有点困惑、这些是十进制形式吗?

    谢谢。
    卢卡斯

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

    你好,卢卡斯-圣,

    我已获得了如下所示的您的问题答案。  您能否告诉我、他们应该如何避免此问题?

    1.下面显示了 DAC8750的外设。   不过、它显示了 AD5420。

    2.他们看到的异常值只有零。  其他选项与问题之前或之后相同。

    配置:0x00

    增益:0x00

    零:0x5530

    状态:0x00

    3.看起来像十进制的数值是系统内部的数值,异常值只有零寄存器。

    此致、

    川崎义和

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

    尊敬的 Yoshikazu-San:

    在之前提供的图片中、为什么 SCLK 会提前停止? 客户的微控制器应提供有效的24位写入命令。
    DAC 无法控制 SCLK 和 SDIN 信号。

    客户还可以使用 CRC 帧错误检查来确保 SPI 数据的完整性。

    谢谢。
    卢卡斯

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

    你好,卢卡斯-圣,

    我们有一个节日周,所以我的答复延迟了。

    他们知道 MCU 在中间停止计时的行为。  这里的问题是、竞争对手的 DAC 在此类情况下忽略输入、但 DAC8750似乎获取数据并更改影响 Iout 的寄存器。  它们可以看到8个时钟的数据、并会停止一段时间、然后在16个时钟的剩余时间内再次恢复。  或16个时钟、然后是8个时钟。  您是否知道 它会在 LATCH=Hi 时停在中间、一段时间后恢复、并且可以更改 DAC8750寄存器?  DAC8750是否需要一次获取24个时钟的数据而不在中间更改 LATCH=Hi?  他们如何基于其系统可能在中间停止发送数据并在一段时间后恢复这一事实来避免该问题?

    此致、

    川崎义和  

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

    尊敬的 Yoshikazu-San:

    数据表(第31页)的第8.5.1.4节提到、如果 SCLK 周期数不正确、将会导致将错误的数据编程到寄存器中。

    第8.5.1.1节提到主机必须在锁存器上升沿之前发出24个位、这意味着所有24个数据位都必须在锁存器的单个低电平周期期间。


    该器件不会检测不正确数量的 SCLK 周期。
    许多较新的 DAC 将不会在所需的 SCLK 周期短的情况下接受故障命令。

    谢谢。
    卢卡斯