[参考译文] TMS320F2800157：SPI 混淆

哇、非常感谢！  

没问题！ 希望上述内容可以解决您的问题。 如果没有、请随时在此处发帖或创建另一个主题

此致、

艾里森

我花了大量时间与被破坏的 HAL 传输字节进行斗争。 更新到了5.02 C2000Ware、它实际可以正常工作。  再次非常感谢。  

我不知道该怎么说。"  

由于某种原因、SPI 控制器仍然不能正确地传输数据。 如您所见、我在 EEPROM 示例中得到 WREN 的值为0x0C、但它是0x06。 我在要传输的所有函数调用以及尝试使用 GPIO 进行芯片选择中看到了相同的行为。  Im 太棒了。  

下面是问题的图片：  

我确保相位和时钟模式设置相同：  

有什么建议吗？

在这个周末工作,没有成功。 SPI 驱动器的函数有发送我需要的数据 x2。  

您好、灰：

您能否尝试在 SysConfig 中将时钟模式更改为极性= 0和相位= 0？ 我看到另一个器件状态的时钟设置："数据在时钟后沿有效"、我将其解读为期望数据在时钟后沿锁存(读取)(在这种情况下、 后沿是下降沿、因为时钟处于低电平空闲状态、前沿是上升沿)。

这对应于无延迟的上升沿：

此致、

艾里森

我可以发送和接收数据、但似乎无法让 FIFO 正常工作、因此我使用了阻塞事务。  

我正在尝试使 FIFO 正常工作

目前、试图使 FIFO 工作的逻辑是 将数据发送到 FIFO 缓冲区、等待使用 FFST 寄存器级别状态填充 RX 缓冲区、然后在发送完毕后将 RX 寄存器清零(因为我要写入地址)。 它运行一次通过主 while (1)循环、但停止下一个循环 、并无限期地等待已清除的 FFST 寄存器级别状态、即使该状态应该已满。

希望这是合理的、如果我能提供更多信息以便更轻松地进行故障排除、请告诉我

谢谢！

灰色

您好、灰：

时钟相位的变化是否提供了帮助？

如果我理解正确、那么问题是 RXFIFO 在您预期的时候未被填满？

请记住、SPI 是一种全双工通信协议、因此您必须传输数据才能接收数据。 问题是否是您正在 从控制器设备传输数据、但在控制器设备上接收不正确？ 或者问题是程序没有启动下一次从控制器到外设的数据传输？

此致、

艾里森

你好、大进展。 SPI 的许多问题都是由硬件问题引起的(完全是我的故障)。

为了让一切变得更简单,我摆脱了 FIFO 的增强,并把 EEPROM SysConfig 和 C 代码作为参考,看起来像 spi_receiveByte ()仍然不工作。 Im 在 MOSI 上得到一个0xD1 (抱歉、在下面的屏幕截图中是它的屏幕外)、但 temp variable 中没有存储任何内容。 C2000ware 的最新版本上的 Im。

您好、灰：

很高兴听到进展！

您能解释一下这个问题的背景吗？ 您是否发送/接收了其他数据、该数据是正确的、但只有0xD1是错误的？ F280015x 是控制器/主器件吗？ SPI_receiveByte 应该接收发送到 F280015x 的数据并将其存储到 temp 变量中；如果您在 MOSI (主器件输出、从器件输入)线路上看到它、那么您是说数据正从 F280015x 发出？ MISO 线路上有什么内容？

此致、

艾里森

我能够成功地传输到我的 SPI 器件以配置寄存器-这样有效。 问题是从 SPI 控制器读回。 我的 Salaea 可以看到使用 receiveByte 和 dummyData 将接收位移出、但该函数的返回 情况不是我在逻辑分析仪上看到的。  

您能解释一下这个问题的背景吗？

-> F280015x 现在使用 SPI_trasmitByte HAL 成功发送数据、但 SPI_receveByte 不会返回我正在使用逻辑分析仪观察到的接收到的值。

您是否发送/接收了其他数据、该数据是正确的、但只有0xD1是错误的？ F280015x 是控制器/主器件吗？

->是的、F280015x 是主器件。 逻辑分析器正在从从器件接收0XD1 (成功)、但 reiceveByte HAL 未返回该值。 这确实意味着 dummybytes 被 成功地移出 reiceveByte、所以这有点起作用。

SPI_receiveByte 应接收发送到 F280015x 的数据并将其存储到 temp 变量中

这正是我现在用它做的,但它不起作用。 最后、我需要接收18个字节、Im 尝试 循环使用 reiceveByte 来完成该操作。 但在测试中、我尝试仅接收一个字节、该字节不起作用。

请记住、我正在使用 GPIO Chipseelct 控制(顺便说一下、它非常好用！)

非常感谢您的支持。

此致！

灰色  

您好、灰：

您如何定义"temp"变量？

一件有助于再次检查的事情是在你有 SPI_receiveByte ()的第236行(或之前)设置一个断点,然后在该行/之前运行程序,然后使用"Step Into"和"Step Over"按钮来查看正在发生的情况。 请尝试逐行通过 receiveByte 函数(当您"步入"函数 并进入 spi_pollingNonFIFOTransaction ()时，应该跳转到 spi.c 文件来执行此操作，因为这就是 receiveByte ()使用的函数)。  

您仍在使用最新的 C2000Ware driverlib、对吧？ 请记住旧版本的 SPI_pollingNonFIFOTransaction ()存在错误。 更正后的版本应如下所示：

很高兴 GPIO 芯片选择进展顺利！

此致、

艾里森

温度变量为 uint16_t 类型。 我刚刚 在新的 Driverlib 5.0.02中检查了 SPI_pollingNonFIFOTransaction (),它和你的屏幕截图一样。 我可以单步执行它、仍然没有得到任何 RX。  

还有其他想法吗？

Hmm 奇怪-要澄清一点、您看到的是 MISO 线路上的正确活动、但它并没有保存到温度变量中？ 当您在运行时检查 SPI RXEMU 寄存器时、是否仍然在 SPI RX 缓冲区中看到正确的数据？

是的、我的逻辑分析仪正是连接到 SPI 线路、因此它  可以看到与 C2000相同的总线、但 SPI RXEMU 据说是0x0000。

我觉得有一些基本的问题,我必须问,以防万一:

• 只是想澄清一下、当您在实际程序中单步执行/通过 receiveByte 时、您看到了经过更正的函数(我在上面绘制了图形)？ 有时发生的情况是、即使您下载了最新的 C2000ware、CCS 也不会拉取 driverlib 更改、除非您在 CCS 工作区中手动重新编译 driverlib 库、因此我只是想确保这不是问题。
• 再快速检查一下、是否在检查寄存器和表达式时打开了持续刷新功能？
• 您是否在程序期间的任何其他时间接收数据、您可以进行检查以验证 RX 线是否正常工作？

另一个想法是尝试使用环回模式(其中 RX 和 TX 在内部连接在一起)、发送测试数据并检查是否正确接收到该数据、以验证至少软件配置正常、并可能提示某些硬件问题。

此致、

艾里森

• 这是本视频系列的第一个

• 已启用持续刷新。  

• 这是 SPIEMU 寄存器的图片。 其 Rxing 0、而逻辑分析仪看到0x64。 是的、我能够接收 RX 值  

RX 从不起作用。 即0xFF 或0x00。  

回送测试在芯片上运行良好。 我们尝试了两个驱动程序库示例。 我不知道如果我能在 Saleae 上读出来，它怎么可能是硬件？  

啊，我看到了！ 很高兴 你能够找到罪魁祸首! 对于它的价值, 调试 永远不会浪费时间在这里-只有更多的教训和获得的智慧 。  

如果一切似乎都正常、我们可以将此标记为已解决、然后关闭该主题！ 但是、如果您完全遇到更多问题、可以随意打开另一个线程。

此致、

艾里森