• 状态 Resolved
  • 已锁定 已锁定
  • 回复 9 回复
  • 订户 0 订户
  • 视图 734 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] Linux/processor-SDK-AM335X：USB 错误数据包 ID

admin
Guru**** 2589300 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/588041/linux-processor-sdk-am335x-usb-bad-packet-id

器件型号：PROCESSOR-SDK-AM335X

工具/软件：Linux

AM335x 上是否存在任何已知的芯片勘误表、可导致在主机模式下在 USB 上发送虚假无效数据包？

我正在搜索损坏的数据包(具有错误的数据包 ID)、这会导致对 URB 中的错误-71 (-EPROTO)进行回调、而没有数据。 这种情况间歇性发生(由于 PID 错误、通常是多个靠近的错误、在 USB 分析仪上观察到)。 我知道至少有一个自定义器件具有一个驱动程序、该驱动程序无法正常处理此问题(可以修复此问题以解决损坏问题)。 这似乎只需重新提交 URB 并继续进行而不会丢失数据就可以清除。 但是，我首先要寻找腐败的根源。 它看起来不是由特定器件引起的。 它看起来像是主机问题。

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

    您是否遇到过有关额外输入令牌的问题

    arago-project.org/.../

    arago-project.org/.../

    arago-project.org/.../
  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    感谢您提供信息。 我不知道这个具体问题。 但是、我认为这不是我看到的结果。 这是一个完全损坏的数据包。 甚至看起来不像输入令牌。 数据包 ID 与其他明显是垃圾数据无效。
  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我要补充的是、很多时候损坏的数据包是 IN 令牌应该位于的位置。

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

    "问题根导致 xDMA 在多个位时破坏数据切换位
    总线主控正在访问 Mentor 内核寄存器空间。"

    数据切换位损坏可能会导致 PID 错误。 但 Processor SDK 是一个最新的软件包、它可能具有此补丁。 您可以交叉验证。 您是否还怀疑信号完整性问题？
  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    谢谢你。 我将研究这个。 这也是一个信号完整性问题。 我处于调查的早期阶段。  

  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我看到的数据中有一个有趣的模式。 每次出现问题时、我都会看到类似的故障模式。

    我们在总线上看到一个0x8D 0x5A、首先触发坏 PID 错误。 有趣的是、它看起来好像器件正在尝试 NAK 0x8D。

    然后、我们可以看到它应该是输入令牌的样子、但它的开头有一个0xCB 字符。 然后、我们看到器件的 NAK、然后看到 SOF 数据包的外观、其中0x8D 位于该数据包的前面、作为额外的字符。 然后，记录器报告错误，因为帧计数已关闭(由于损坏的 SOF 数据包)。 这似乎是主机问题、但我不知道这些额外字符是如何在总线上结束的。

    其中一些 DMA 问题是否会导致这种情况？

    下面是 USB 跟踪片段的文本版本、其中包含错误。

    数据包编号
    _________ ________________________________________________________________
    _________ |标记( 在坏 PID、USB 2.0上触发

    错误：标记#1 )
    _________ |通道0
    数据包(13214152) Dir (？) H (S)数据(8D 5A)错误
    _________ |持续时间(116.667 ns)时间(2.104 ms)时间戳(21281 . 89 679 500)
    _________ ________________________________________________________________
    _________ |标记( 错误：标记#2

    IDLE：错误启动 )
    _________ |通道0
    数据包(13216410) Dir (?) H (S)数据(CB 96 C1 07)错误
    _________ |持续时间(150.000 ns)空闲(2.916 us)时间戳(21281。 991 783 300)
    _________ ________________________________________________________________ Marker(. Pktlen：标记#3. ) Ch0
    数据包(13216411)
    _________ |目录 H (S) NAK (0x5A)数据包长度(6)持续时间(100.000 ns)空闲(2.600us)
    _________ |时间戳(21281 . 786 366 991)
    _________ ________________________________________________________________ Marker(. 数据：标记#4. ) Ch0
    数据包(13216412) Dir (？)
    _________ | H (S)数据(8D A5 A3 73)错误持续时间(150.000ns)时间(110.215ms)
    _________ |时间戳(21281 . 991 789 066)
    _________ ________________________________________________________________
  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    您能否尝试 PIO 模式(非 DMA 模式)并检查这是由于 DMA 还是仍然存在？
  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我会尝试一下。 但是、我看不到软件在哪里会导致令牌或 SOF 数据包格式错误。 看起来软件会触发 IN 令牌并更新帧计数、但外设会执行所有低级工作来形成适当的数据包并发送数据包。

    我在芯片勘误表中注意到了此通报...
    Advisory 1.0.11 USB：连接了响应的非兼容 USB 设备
    伪波无效的短数据包可能会锁定总线

    它声称这在器件版本1.0之后是固定的、但问题是什么是固定的？ NAK 对伪无效短数据包或先发送的伪无效短数据包的处理？

    伪波无效短数据包听起来与我看到的内容非常相似、但我使用的是2.1器件。
  • 0
    TI__Guru**** 2589300 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    关于输入令牌包和 SOF 包、MUSB 控制器应软件请求生成数据以发送/接收数据。 USB 协议在 MUSB 硬件中实现。

    一个想法：
    您能否在 MUSB 驱动程序中添加日志以检查有多少个传输排队到 MUSB 层以及有多少个从 MUSB 硬件获取传输完成回调。 这可以让您了解它是否是伪波并在代码之外生成。