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.

[参考译文] MSP430F5528:USB 处于设备模式:了解偶尔不确认 USB 批量输出数据包的情况

Guru**** 2447540 points
Other Parts Discussed in Thread: MSP430F5528, TMS320F28375D, MSP430F5529

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

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/970700/msp430f5528-usb-in-device-mode-understanding-occasional-no-acknowledgement-to-usb-bulk-out-packets

器件型号:MSP430F5528
主题中讨论的其他器件: TMS320F28375DMSP430F5529

大家好、我正在寻找有关如何调试 USB 大容量数据包问题的指导。

设置:

我有一个 TMS320F28375D 处理器用作 USB 主机、还有一个 MSP430F5528用作 USB 器件。 它们位于单独的定制板上、具有其他功能。 它们的 USB 信号直接相互连接、并且只相互连接、并且正在进行全速 USB 通信。 它们之间的电缆是一个用于 D+/D-的简单双绞线、而 TMS320板与 MSP430板之间提供了电源和接地。 由于提供3.3V 电压、我们不使用5V VBUS、从 USB 的角度来看、MSP430是"自供电"的。 我们在示波器和逻辑分析仪上查看了 D+/D-信号、信号看起来稳定且正确。

除了枚举之外、MSP430为所有流量提供了一个批量输入和批量输出端点、枚举通常在端点0上成功发生。 TMS320使用大量修改自键盘主机示例的代码、而 MSP430使用自定义版本的 PHDC 驱动程序。 TMS320能够从 MSP430发送(批量输出)和接收(批量输入)数据;MCU 在两端正确接收数据。

由于这是一个相对较高的数据吞吐量用例、TMS320通常向 MSP430发送一系列最大有效载荷大小的数据包(64字节)。 根据正常 USB 规范、在发送下一个数据包之前、每个数据包都必须被连接。 目前我们看到偶尔会有 NAK,因为 MSP430还没有准备好下一个数据包--这不是我们要解决的问题,因为我们预计 MSP430 MCU 代码的响应速度不够快。  

问题:

~10%的时间、MSP430不会确认批量输出数据包。 这种缺乏确认的情况可能会发生在任何大小的数据包中(我们到目前为止已经尝试过)。 TMS320 USB 模块最多将重新发送3次数据包、并且在大多数情况下、其中一次重试成功并且传输继续。 我们正在发送足够的数据、最终连续3次重试失败、而 USB 模块"放弃"尝试发送数据包并引发 MCU 错误。

如果 TMS320在每次出现此错误时重新安排同一个数据包、最终会看到一个 ACK 并且程序继续进行。 虽然我们可以"逾越"这个问题、但我们担心 MSP430缺乏确认的严重原因、并且由于所有重发、总体带宽会降低。

附件是在小数据包中出现此问题的屏幕截图。

我们已通过电气方式检查连接并尝试调整滤波、但到目前为止、没有任何改变。 这种行为不仅与我们的定制 MSP430板一致、而且与 TS430"ZIF 插座"开发套件和 MSP430F5529 Launchpad 开发套件一致。

问题:

在 MSP430方面、我看不到一种方法来告诉您为什么单个数据包没有被应答。 用户指南显示"如果在接收到数据包时发生 CRC 或位填充错误、则不会向主机返回任何握手。" CRC 在重新传输之间似乎没有变化、我不确定如何在示波器上识别"位填充错误"、但 EOP 转换的时序看起来是相同的。

我是否遗漏了任何东西或应该研究什么? 感谢您的帮助!

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

    您好、Matthew、

    从我在 USB 中搜索"位填充"时可以找到的内容:

    时钟被传输、与差分数据一起编码。 时钟编码方案为 NRZI (不返回到零反相)。 在 NRZI 中,‘1’由电平无变化表示,‘0’由电平的变化表示。 一个0字符串引起 NRZI 数据每一次切换、而一个1字符串引起长周期、数据中没有转换。 此外、为了确保足够的信号转换(用于保持 DPLL 锁定)、  还采用了位填充。 在对数据进行 NRZI 编码之前、在数据流中的六个连续1之后插入一个零、这会强制在 NRZI 数据流中进行转换。

    我将假定位填充错误将由意外(或压倒)的"位填充"触发。  如果是这种情况、"位填充"的发生不应太高、除非您传输大量不会改变值的数据。

    BR、
    Leo

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

    您好、Leo、

    感谢评论--我们看到 NRZI 编码没有问题,包括发送一系列1时的位填充。 MSP430会像其他数据包一样频繁地对填充了位的数据包进行确认、因此我认为 TMS320并不总是位填充错误。

    我无法找到填充位缺失或过于频繁的数据包、并且位脉冲持续时间与位脉冲持续时间大致相同。 因此、似乎不太可能出现问题。

    今天我要获得一个硬件 USB 协议分析器来确认 TMS320正在正确地生成 CRC -如果有其他关于查看位置的建议,我将不胜感激!

    -Matt

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

    您好、Matt、

    另一个想法可能是使用另一个5529 Launchpad 作为主器件、并查看是否存在相同的问题。 这至少应该澄清问题是在主机还是从机端。


    BR、
    Leo