• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 0 subscribers
  • Views 209 views
  • Users 0 members are here
Options
Options
Similar topics

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.

[参考译文] DAC38RF97：SPI 非无反应-不接受写入

admin
Guru**** 1568665 points
Other Parts Discussed in Thread: DAC38RF97
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/883095/dac38rf97-spi-non-reactive---not-taking-writes

器件型号：DAC38RF97

我们无法使 DAC38RF97接受写入。  我们向 DACCLK 和 SYSREF 提供了一个80MHz 信号(在示波器上验证)、并向 DACCLKSE 提供了一个100MHz 信号。  我们已验证所有电压是否正确。  我们已经验证了 SLEEP、jtrstb、testmode、DAC_GPI0、DAC_gpi1是逻辑零(它们由 FPGA 驱动)。     我们还能够验证是否可以手动切换 resetb。  在复位后、我们使用 BusPirate SPI 主站执行所连接的脚本。  FuseFarm 似乎已经被加载、如读取时所示、0xff = 0x89。  目前、我们正在查看 ATEST 并写入0x01以选择并希望读取电压、以指示 SPI 能够正确写入。  我们无法写入并随后读取多个地址、包括地址0x09。  哪些因素可能会妨碍我们撰写文章？  请访问 appreciated...e2e.ti.com/.../200224_5F00_192106-BusPirate-capture.txt

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

    您好！

    您能否检查 DVDD 电源是否稳定？ 确认后、我们可以为您进一步研究。

    －Kang

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

    所有电源都非常干净。  是否存在我应该研究的电源定序问题？

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

    我还通过 RESETB 验证了电源是否稳定/无毛刺脉冲。  

    我们确实观察到、在我们实施了 SYSREF 和 DACCLK+/-之前、FuseFarm 完成位没有复位、尽管我们以80MHz 的频率运行、这可能低于规格。  最初、我们仅实现了 DACCLKSE。

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

    您好！

    Fusefarm 加载要求向 DAC 注入时钟、以便开始熔丝加载过程。 这是预期的。

    请提供 SPI 总线读/写的 SCLK/SDENB/SDIO 引脚的示波器截图。

    您可能正在配置不匹配的3线或4线模式。 您需要确保 SPI 总线与3线 SPI 模式或4线 SPI 模式相匹配、这是由寄存器1位7设置的。 在3线模式下、回读来自 SDIO 引脚。 在4线模式下、回读来自专用 SDO 引脚。 我看到您希望使用3线模式、因为您能够在复位时回读。

    另请告知您如何处理 SPI 指令中的 r/w 位。 听起来您可以正确读取但不能写入。 命令中的唯一区别是 SPI 指令中的 r/w 位。 最好在示波器中探测准确的时序、逐位找出 SPI 事务。

    －Kang

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

    我们正在通过 FPGA 进行工作。  但是、现在、我们始终在 SDO 上读回、并始终在 SDIO 上写入。  如果我们处于4线制模式、SDIO 是否可以始终由处理器驱动、或者必须在回读期间进行三态处理。

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

    这显示了一系列命令。  我添加了第一个、以显示我们实际上处于4线模式。

    [0x01 0x18 0x80]
    [0xFF r r]
    [0x81 r r]

    包括捕获文件和范围图。  我已放大每个图。  所有图的顺序从上到下如下：

    SCLK (黑色)
    SDEN (蓝色)
    SDIO (绿色)
    SDO (红色)

    数据如下：

    [0x01 0x18 0x80][0xff r r][0x81 r r]
    /CS 被启用
    写入：0x01
    写入：0x18
    写入：0x80
    /CS 被禁用
    /CS 被启用
    写入：0xFF
    读取：0x80
    读取：0x09
    /CS 被禁用
    /CS 被启用
    写入：0x81
    读取：0xC0
    读取：0x04
    /CS 被禁用

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

    您好！

    我看到您没有设置为4线模式。 我看到寄存器1 (来自您的连接配置)的位7设置为0。 要访问4线模式、您需要将该位设置为1。

    在4线制模式下、您不必对 SDIO 进行三态处理。 SDO 是专用读数、SDIO 是专用输入。  

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

    我看到我省略了示波器捕获中的第一个命令(但我在命令日志中确实有它)。  抱歉！  看起来我正在正确写入它、但当我读回它时、它返回错误。  启动时的快速查询... 序列应为：

    根据图150：

    1. 应用时钟、复位
    2. 写入0x01 0x81 0x80将其放入4W。
    3. 读取0x7f -检查位15。  我观察到 SDO 始终处于活动状态、与(2)无关。
    4. 如果失败则重做、如果通过则继续。

    第一个命令是(注释突出显示、在第一个和第三个命令中-在本答复的后面部分)：

    [0x01 0x18 0x80][0xff r r][0x81 r r]
    /CS 被启用
    写入：0x01
    写入：0x18
    写入：0x80
    /CS 被禁用

    第三条命令读回错误：

    /CS 被启用
    写入：0x81
    读取：0xC0
    读取：0x04
    /CS 被禁用


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

    您好、Rolf

    能否确认您正在执行以下操作？

    地址= 0x01、寄存器值= 0x1880？  

    [引用 USER="Rolf Wendt"[0x01 0x18 0x80][0xff r r][0x81 r r]
    /CS 被启用
    写入：0x01
    写入：0x18
    写入：0x80
    禁用/CS [/报价]

    如果是、SCLK 为什么不是连续的？ 相反、它们被分成3组、每组8位。 应该有一些 FPGA IP 可以在没有连续 SCLK 的情况下执行预定义的 SPI 总线写入/读取。

    此外、对于0x01寄存器的回读、我没有看到 READ 位处于逻辑高电平。 请参阅下面的捕获：

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

    目前、我们不是通过 FPGA 直接管理状态机、而是使用通过 FPGA 进行缓冲的 PC。  它将逐字节运行、不能设置为使用持续平滑的时钟流运行、这通常是 SPI 所能接受的。  如果需要连续时钟流、我们将实施该方法、尽管可能需要几天时间、但数据表中似乎并未要求这样做。

    对于字节序列、这是序列和响应：

    字节1

    字节2 (读取)：

    字节3：

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

    康

    我现在已经在多个电路板上尝试过这种方法、因此问题始终如一。  读取0xff 和地址的其余部分之间存在一些不同。  很明显、如地址0x7f (0xff 命令)所示、闪存组工作正常。

    与该地址和所有其他地址有何不同？  我尝试读取几个寄存器。  请参阅以下内容：

    1) 1)写入地址0x01：

    写入：0x01
    写入：0x18
    写入：0x80

    2) 2)读取0x7F：
         
    写入：0xFF
    读取：0x80
    读取：0x09

    这是预期中的...

    3) 3)读取0x01：   

    写入：0x81
    读取：0xC0
    读取：0x04

    这不匹配！！！！

    4) 4)读取0x09：

    写入：0x89                                                             
    读取：0xFC                                              
    读取：0x00

    5)写入0x09 (设置为第2页、仅用于启动：

    写入：0x09
    写入：0x00
    写入：0x02
             
    6) 6)读回0x09以检查：

    写入：0x89                                                             
    读取：0xFC
    读取：0x00

    这毫无意义... 虽然0x7F 工作正常、但其他任何一个看起来都不工作。  我们也使用 ATEST 进行了一些实验、但看起来并不像器件正在进行写入。

    我相信所有时钟都在工作。  DACCLKSE 和 DACCLK 上为100MHz
    DACCLK_N 和 SYSREF 上的200MHz。  
    TRST 为低电平
    TESTMODE 为低电平
    睡眠为低电平
    大约500mSec 后 RESETB 处于高电平

    我已经三次检查了引脚分配和电压。

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

    在我进行测试时、无论 SPI4_EN 的状态如何、在测试期间、SDO 似乎始终是复位后的有效信号。  请确认。

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

    您好、Rolf、

    我已要求更熟悉此器件的另一位工程师对此进行研究。 我们将在下周的下半年回来。  

    －Kang

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

    您好、Rolf、

    SDO 具有弱内部上拉电阻、因此在器件复位后它将为高电平。

    谢谢、

    埃本

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

    这不是问题。  SPI 总线似乎无法处理3个字节的数据... 但是、我们需要24位的连续时钟。  这是在 FPGA 中实现的、并解决了问题。  我认为、多毫秒时钟暂停是问题的根源。  我们正在处理这个问题。