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.

[参考译文] ADS130B04-Q1:协议通信问题

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

https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1125650/ads130b04-q1-protocol-communication-issues

器件型号:ADS130B04-Q1

大家好、

我最近集成了此 ADC 差分转换器 IC、并在通过 SPI 读取和写入寄存器方面遇到了困难。 我正在使用 RPI 与其进行通信。

我的设置如下。

CLKIN -> GND

SYNC_RESET ->上拉至 VDD

DRDY -> NC

CS   <-连接到我的 RPI SS

SCLK <- RPI SPI 时钟输出

DIN  <-- MOSI RPI

DOUT -> MISO RPI

我已经用示波器分析了这些信号、我很确定它们是否正常。 SPI 配置为模式1、最高有效字节发送和24位字大小。 主时钟的频率已从10Kbps 更改为1Mbps、但未成功。 在下面、您还可以找到 RPI 的通信输出和输入。

NULL command data response:
DATA BYTES 0xff54 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0xac79 - Padded 0x00


RESET Output message:
DATA BYTES 0x0011 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


RESET Read message:
DATA BYTES 0x0511 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0xf71a - Padded 0x00

UNLOCK Output message:
DATA BYTES 0x0655 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


UNLOCK Read message:
DATA BYTES 0x0655 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x3d
DATA BYTES 0xc680 - Padded 0x02


------------------------------------------


NULL command data response:
DATA BYTES 0x0500 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x7b8d - Padded 0x00


WAKE UP Output message:
DATA BYTES 0x0033 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


WAKE UP Read message:
DATA BYTES 0x0533 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0xf71a - Padded 0x00


------------------------------------------


NULL command data response:
DATA BYTES 0x0500 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x7b8d - Padded 0x00


Mode Register Write Output message:
DATA BYTES 0x6100 - Padded 0x00
DATA BYTES 0x2902 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00


Mode Reg Read message:
DATA BYTES 0x6b00 - Padded 0x00
DATA BYTES 0x2902 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x7b
DATA BYTES 0x8d00 - Padded 0x05


------------------------------------------


NULL command data response:
DATA BYTES 0x0500 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x0000 - Padded 0x00
DATA BYTES 0x7b8d - Padded 0x00

NULL 命令是唯一返回默认状态寄存器为0x500的命令。 然而、当 MODE 寄存 器被置位时、这个命令的答案应该是0x4200、而不是0x6b00、并且零填充字节中也没有任何原因找到了一些字节。 即使答案是错误的(根据2021年11月的数据表 SBASAD2)、即使寄存器 CRC 已启用(位13)、该命令之后的状态寄存器也不会改变、CRC 类型也已更改为 ANSI (位11)。

希望获得任何线索。

此致、

Martín μ A

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

    尊敬的 Martin:

    感谢您的发帖、欢迎来到我们的论坛。

    (忽略我的初始答复、因为输入 CRC 默认为禁用状态)。

    在第89行中、您好像启用了寄存器映射 CRC、但不启用 SPI CRC。  您是要启用这两者吗?

    是否可以在逻辑分析仪上捕获这些连续帧以查看整个序列? 有一点不清楚"数据字节"的每个块是与数据写入还是数据读取有关(即第87 - 93行看起来像 DIN 上的 WREG 帧)。 在 DOUT 上是否读取了第97 - 102行响应? 这是同一帧还是下一帧?)。

    示波器或逻辑分析仪捕获会有所帮助。 如果您也使用 Saleae、我们还可以直接导入 Saleae 捕获文件并查看整个命令序列。

    此致、

    Ryan

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

    您好、Ryan、

    感谢你的帮助。

    首先、我将寄存器映射 CRC 理解为 ADS130B04器件配置寄存器的 CRC、但在我最终使其与器件正确通信之前、我不是很感兴趣。 您是说没有 SPI CRC、寄存器映射不应该被启用吗? 如果是、您能告诉我原因吗?

    我目前无法使用逻辑分析仪捕获帧、我将尽快发布它们。

    有关初始帖子中的数据。 我在数据表中看到、器件对下一帧中的命令负责、但对我来说、它在命令的同一帧中应答、因此我选择发送命令、然后发送 NULL 命令。

    也就是说,文件的结构是由 RPI 发送到  ADS130B04器件的数据(即 ADS130B04器件在其 DIN 中接收的数据),在同一帧中输出( ADS130B04器件通过 DOUT 发送的数据) 然后是器件对 null 命令(即下一帧的数据)的应答。

    希望这有助于了解数据。 总之、不会打印 Null 命令、因此"NULL 命令数据响应"代表 ADS130B04器件对 null 命令的应答。

    我将尽快发布捕获。

    此致、

    Martín μ A

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

    尊敬的 Martin:

    Ryan 在本周剩余时间内不上班。 让我看看我是否能在这段时间内提供帮助。

    SPI CRC 和寄存器映射 CRC 彼此完全独立。 您可以同时启用或不启用这两个选项。
    我还尝试遵循您的上述协议。 某些回答肯定没有意义、您也不应该在填充区域中看到任何位。 调试这种情况的第一步实际上是查看示波器或逻辑分析仪上的通信。

    您是否按照上述顺序执行上述协议、并且命令之间没有任何间隙?
    例如、在执行 RESET 命令后、您不应立即与器件通信、因为器件需要完成复位过程。 复位后也无需解锁器件、因为器件默认处于解锁状态。 复位后不需要 WAKEUP 命令。

    此致、
    Joachim Wuerker

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

    您好、Joachim、

    感谢您的回复。  每组命令之间只有50ms (NULL 命令响应、命令输出消息和命令读取消息)。

    此外、提供的数据中没有逻辑命令序列。 我的目的是更好地提供更多信息。 这就是我尝试随机命令的原因。

    我的初始方法是发送复位命令、然后等待50ms、使用所需的配置写入寄存  器、读取寄存器、然后读取 ADC 数据、以检查配置是否是所需的配置。 但是、由于没有发生这种情况、我只尝试了一些命令来查看答案是否正确。

    为了添加更多信息、我还尝试使用器件的另一个单元和另一个 Micro 通过 SPI 发送命令、以防该单元出错、但我没有成功。 它具有相同的行为。

    希望星期一我将有一些示波器捕获。

    此致、

    Martín μ A

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

    尊敬的 Martin:

    感谢您的澄清。 您描述的序列:"发送复位命令、然后等待50ms、使用所需的配置写入寄存  器、读取寄存器、然后读取 ADC 数据、以检查配置是否是所需的配置。" 是正确的。

    让我们希望示波器捕获将提供更多见解。 至少对 NULL 命令的响应似乎是正确的。 在我看来、与您有关 DIN 的数据类似的事情并不完全正确。 您是否确认 SCLK 空闲时间低?

    此致、
    Joachim Wuerker

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

    尊敬的 Martin:

    您是否在这段时间内成功地查看了具有示波器的 SPI 信号、或者您是否已经解决了通信问题?

    此致、
    Joachim Wuerker

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

    您好、Joackim、

    感谢您的所有支持、最后我的硬件同事得出的结论是、这是由硬件问题引起的。

    在硬件修复之后、我们最终能够进行通信并成功获取 ADC 数据。

    此致。  

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

    尊敬的 Martin:

    感谢您的更新。 我们很高兴您找到并解决了该问题。

    如果您将来有任何其他问题、请告知我们。

    此致、

    Ryan