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.

[参考译文] TMS570LC4357:数据包间的 SPI 延迟

Guru**** 2468610 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1038285/tms570lc4357-spi-delay-in-between-packets

器件型号:TMS570LC4357

你好  

我已经为 TMS570芯片的 QSPI MIBSPI5设置了一个裸机驱动程序。 不过、您会注意到每个16位数据包之间存在延迟、如我的逻辑分析仪的以下屏幕截图所示。 对于25MHz 时钟、每个时钟突发之间的延迟约为100ns。 我在四条数据线上发送128个16位数据包的猝发。
mibspi5的 txram 中每个缓冲器的 WDEL 和 DFSEL 位都设置为0、我直接在 ram 中进行了检查。 SPIFMT0寄存器的 WDELAY 位24至31设置为0、SPIDELAY 寄存器的所有位都设置为0、我使用调试器直接在寄存器中进行了验证。 我缺少什么、为什么存在该延迟? 我希望我可以连续发送数据、而不会在 clk 行中暂停?

CLK
1. CS (不起作用、将单独解算)

2-5. MOSI 0-3.



非常感谢您提供的任何帮助!

肖恩

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

    您好 Sean、  

    看起来使用的是并行模式。 两次传输之间的延迟为 T2CDelay + C2TDelay = 3*VCLK 周期。 您的设置中的 VCLK 是什么?  

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

    我的 VLCK 为75MHz、并且寄存器 SPIDELAY 中的 T2CDelay 和 C2TDelay 都为0

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

    此外、在所有传输之间、CSHOLD 设置为1、除了最后一个传输。

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

    您好、知道 vclk 为75MHz 时、您是否会有关于延迟原因的更多信息? 我只会期望一个时钟周期作为突发之间的延迟。  

    谢谢!

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

    对于常规 SPI 传输、如果 CSHOLD 设置为1且 WDEL=0、则2传输之间不应有延迟。

    下图显示了使用 SPI3进行的2个字传输。 字 length=16位、且 CSHOLD 被置位。

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

    您好 QJ、

    感谢您的回答! 不过、这不能解决我的问题、因为我已经正确配置了 WDEL 和 CSHOLD。 这就是为什么我如此神秘地认为拖延是一件事。  

    我直接在 RAM 或其各自的寄存器中读取了以下值、因此我知道它们是正确的:

    WDEL = 0
    CSHOLD = 1  
    C2TDELAY = 0
    T2CDELAY = 0
    WDELAY = 0
    我在发布后也修复了 CS、它运行良好。 我可以在 CS 线路上看到、它在整个128个数据包传输过程中保持低电平、这符合预期。

    这可以并行使用 QSPI、而不是常规 SPI。 两者之间的延迟是否存在一些差异? 我希望不会出现这种情况、正如 TRM 中所描述的那样。  

    我可以向您提供哪些信息来帮助您解释这种行为?  

    再次感谢、  

    肖恩

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

    我还可以看到、您在示波器图中使用的是1MHz 的 SPI 时钟、在1MHz 时使用逻辑分析仪、我可以看到在100ns 的 mibspi 中的突发之间仍然存在大约100ns 的延迟。 尝试将25MHz SPI 时钟的预分频器设置为2、以查看是否可以重现延迟?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    [引用 userid="499271" URL"~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1038285/tms570lc4357-spi-delay-in-between-packets/3844447 #3844447"]这可以并行使用 QSPI、而不是常规 SPI。

    您是说并行模式下的两个字传输之间没有延迟吗?

    我将使用更快的 SPI 速度(25MHz)进行测试。 100ns 的延迟可能是由于在 API 中执行 while (blocksize!= 0U)循环中的代码而导致的。

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

    在多缓冲模式(MibSPI)中、 多个传输在开始传输前排队、因此传输之间没有延迟。

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

    抱歉、我是在并行 SPI 中配置的、而不是在单个 SPI 中进行上述测试、即使该延迟始终存在于单个或并行模式中。 我也不使用 API、而是我自己编写的裸机驱动程序。 通过启用 TGENA、代码等待整个 txram 填充、然后再发送、因此不存在"代码"延迟的可能性。 我甚至可以在启用 TGENA 之前暂停调试器、以确保 TXRAM 已满我想要的值、并且延迟仍然存在。 (只是为了确保我还在未连接调试器的情况下测试了这个、并且延迟也存在)

    此外、即使我将 VCLK 的频率更改为小于75MHz 的值、延迟似乎始终与 VCLK 的大约8个周期成比例。  

    我在这里添加了一个所有寄存器和 TXRAM 的状态图像、以防您看到我不会看到的情况。

    再次感谢、

    肖恩

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

    您好 Sean、

    感谢您提供如此详细的信息。 我今天很忙、明天就要运行测试。 很抱歉耽误你的时间。

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

    好的,谢谢你们的帮助!

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

    您好 Sean、

    我注意到每次传输之间的延迟。 延迟约为6个 VCLK 周期。

    如果 CPU 或 DMA 控制器在缓冲区传输完成时访问多缓冲区 RAM、并且序列发生器在传输完成后尝试将接收到的数据写入 RXRAM、 然后、由于总线仲裁逻辑、序列发生器在获得总线之前可能会有几个 VCLK 周期的延迟。  

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

    因此、如果我理解正确、这是序列发生器的限制、除非我们在 VCLK 上获得更高的值、否则无法以任何方式降低该延迟? 如果是这种情况、我将在解决后关闭此 TT。

    我可以说、参考手册中没有对此进行说明。 第1503页上只有一个关于总线仲裁的小话术。 如果没有解释、我建议在参考手册的下一版中以口头方式或带有时序图的方式进行介绍。  

    非常感谢您的帮助、您非常出色!

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

    您的理解是正确的。 无法减少6个 VCLK 周期的延迟。  

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

    再次感谢!