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.

[参考译文] CC3235MODSF:I2C 从 DMA -传输损坏、之后无 IRQ

Guru**** 2558970 points


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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1023009/cc3235modsf-i2c-slave-dma---corrupted-transfer-and-no-irq-afterwards

器件型号:CC3235MODSF

我正在尝试使用 DMA 支持设置 I2C 从设备、并遇到了在传输中有时获取随机值的问题。

我将始终发送40个字节、并使用1个原子例程将这些40个字节复制到 DMA_TX_buffer、然后设置 DMA 以进行传输。
出于这个问题的调试目的、我只使用递增值和将缓冲区扩展8个字节、这些值包含"BUFEREND" 文本、缓冲区的第一个字节与其余字节不同。

下图显示了主器件的 IRQ 信号(低电平有效)。 显示发送了许多 I2C 消息、除了最后一条消息外、所有消息看起来都是正确的。

要放大最后一封邮件:

在这里、我们看到 IRQ 信号变低、开始传输、在随机字节数后发送一些垃圾。
字节数正确。 -> DMA 传输计数正确、但 SRC 地址损坏?!
在这种情况下、IRQ "DMA_TX_DONE"也不会发生、并且我的应用的 I2C 任务通过等待这个事件而被暂停。

当这个问题出现时、我还检查了 TX 缓冲区、在调试器中、缓冲区看起来是这样的(在我看来完全正确):

所有的字节都是正确的、40个字节的值是递增的。

我已经尝试过:

-交换到不同的 DMA 通道。 最初使用的是 CH25-CH26、但怀疑这可能与 SSPI 相冲突、然后换用至 CH31-CH30、GSPI 被分配至 CH7-6
-播放转接计数。 现在是40。 如果我将其设置为较低的值、则它会正确传输较少的字节(并在主器件等待40时挂起通信)。
直接将 SDR 寄存器用作 DMA dst ->不起作用。 只有 FIFO 工作
-刷新 FIFO /在重新配置 DMA 之前不刷新 FIFO
-将 TX 仲裁设置为更高的值

有什么关于如何进一步调试的想法吗?

什么可能导致 N 个传输正确、然后恰好在突然1个传输中的随机位置损坏?

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

    您好!

    这可能是您的应用中的某个内容-我不熟悉有关 I2C (或 DMA)的类似问题、但我将进行检查。

     您能否在 DMA 完成时验证 TX 缓冲区的内容(可能是因为堆栈溢出而被覆盖)。

    您 的平台可能偶尔会出现电源压降(您使用的是 TI Launchpad 还是定制板)?

    BR、

    Kobi

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

    我发布了一张图片、展示了出现问题后的缓冲区内容。 100%匹配预期内容、您可以看到最初的几个字节也与传输的字节匹配。

    您是不是说 CPU 电源轨下降导致一些外设被取消初始化? 如果这是一个完整的 CPU 断电、我希望 WiFi 重新连接或传输的字节数出现问题。

    但是、发送的字节数始终是预期的数字(发送的40个字中的40个字)。
    当故障发生时、也不会发生 IRQ。

    这向我表明、DMA 已/将会以某种方式使用看似固定的随机源重新配置、并在特定点后以静态随机值馈送 FIFO。 此外、DMA 传输计数似乎会损坏、因为在这种情况下不会发生 TX_DMA_DONE IRQ。

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

    您能否使用参考平台(CC3235 Launchpad)重现此问题?

    TX 缓冲区中是否需要"159"的值?  

    失败后、您是否能够获得以下交易? 这些数字是否会从最后一个良好的数字继续进行?

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

    是的、问题与电路板/原理图无关。

    是的、传输的第一个数据字节被更改、所以我可以识别  DMA 源或设置是否存在毛刺脉冲。 在这种情况下、第一个字节从158增加到159、因此是预期的。

    由于此时应用程序正在等待 CPU 信号、因此无法进行进一步的事务处理。
    我还没有尝试通过强制清空 FIFO 并重新配置 DMA 来解决这一问题。

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

    您是否提到 src 地址已损坏? 您是否检查了寄存器(失败后)?

    您的代码是否可能正在写入寄存器区域(可能是某些堆栈溢出或其他内存问题破坏了该区域)。

    您是否尝试过使用 CC3235 Launchpad?  

    功率干扰可以解释寄存器损坏和事务从未完成的原因。

    您能否在事务之间添加一些间距(睡眠)、并查看是否有更改?

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

    我只是怀疑 SRC 地址会受到指责。   DMA 以正确的字节数压入 FIFO 的随机数据至少指向仅损坏 SRC addr 的故障模式。  如果发生任何其他 DMA 故障(目标错误、传输计数错误)、每次都将导致未完成的传输/不正确的传输。
    奇怪的是、经过重新写入的数据总是用相同的字节填充、因此似乎 SRC 地址损坏、在这种情况下增量机制也不起作用。 通常情况下、SRC 应增加1个字节、因此如果它跳转到随机地址、它应该是垃圾(更改数据)或0xFF (擦除的闪存区域)、但不是0x7F 或0x1B 或某些任意值。

    我尝试检查 HW 寄存器、但寄存器是存储器映射的、一旦传输完成、DMA 就会将其清除。 除非有寄存器显示我错过的最后一个传输状态、否则我恐怕无法实现。

    否、我尚未尝试使用 Launchpad。 我在 launchpad 上重现了另一个问题(不会发生 TX_empty)、但在这个问题上没有。
    我们目前使用的是 MODSF 型号、因此原理图非常简单(仅使用 GPIO 和 I2C、不复杂)。 我还使用模拟探针检查了 I2C 线路、它们看起来不错、问题似乎与 SW/CPU 有关。

    传输不是周期性的、它是由事件驱动的、我通过一个 WebSocket 数据包触发它(当接收到数据包时、发送 I2C 消息)、它在一段时间后发生(发送 N =任意数量的数据包后)。 时间似乎没有这方面的作用,至少不是发送频率。

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

    以及其他问题: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1023341/cc3235modsf-i2c---i2c_slave_int_tx_fifo_empty-is-only-asserted-when-transfer-is-ongoing/3785860#3785860

    在我看来、内部 FIFO 请求信号在 CPU 中会以某种方式丢失?

    将解释 DMA 不再送入 TX FIFO 的原因、或为什么没有发生软件 IRQ

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

    我不确定您的一些假设(例如、出错时的预期值)。

    如果您可以为 Launchpad 提供代码来重现此情况(假设我们还可以获取主器件)、我很乐意尝试对此进行调试。

    目前、由于此问题发生在非常基本 的用例中(在这种情况下、预计其他客户也会面临此问题)-我认为它与硬件问题(您是否已通过设计审查流程 :https://www.ti.com/tool/SIMPLELINK-WIFI-DESIGN-REVIEWS)或某些应用问题有关。

    BR、

    Kobi

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

    当将应用程序片段移植到 Launchpad 时、我们无法重现问题(主从配置中为2个 LaunchPad)、从而指向与硬件设计相关的问题。

    进一步的调试显示了 I2C SCL 线路上的5-20ns 毛刺脉冲、导致额外的边沿和传输损坏。  

    在检查信号完整性时、我们发现在 SCL 附近运行的2MHz 时钟线会在上升沿导致轻微的10-20mV 失速。

    激活 MPTR 寄存器中的毛刺脉冲滤波器似乎可以解决问题、DMA TX 完成 IRQ 工作正常。