[参考译文] TM4C1294NCPDT：使用 SW-TM4C-2.1.0.12573但不使用等时 EP2时等 EP1上的数据损坏

您好 Brian、

[引用用户="Brian Willoughby"]

TM4C USB 外设在等时流模式下的验证效果如何？

[/报价]

与我看到的其他模式不同、看起来整体而言、很多人都在使用这种模式。 无论是这样还是如此出色、几乎没有人来 E2E 论坛提问。 尽管 我喜欢我们的产品和 TivaWare、但我认为后者不会解释缺少有关同步模式的问题。

[引用用户="Brian Willoughby"]

有多少人使用多个端点？

[/报价]

许多用户正在使用多个端点。

[引用用户="Brian Willoughby"]

有多少人的数据包大小超过256字节？

[/报价]

这种情况经常发生、但有一个问题已被裁剪掉、我将在下面进行介绍。 根据您描述的症状、我不确定这会对您造成影响、因为问题通常表现为锁定 USB、而不仅仅是损坏数据包。

[引用用户="Brian Willoughby"]

我已经查看了勘误表、没有发现会影响这一点的 USB 问题。 USB 库中是否有记录的错误修复？

[/报价]

首先、您应该根据 TivaWare 阅读最新版本说明、以跟踪从2.1.0到2.1.4的所有 USB 库更改。

出现的另一个问题涉及 USBHCPDPipeWrite API。 有关详细信息和正确的解决方案、请参阅以下文章： e2e.ti.com/.../2131893

[引用 user="Brian Willoughby"] USB 库或 USB 外设是否可能未正确报告0字节数据包？

我需要查看我是否可以跟踪我帮助解决的有关此类数据包的问题、我不记得报告/响应是否失败、 但我不太清楚的是、在过去几个月中、论坛上出现了一个涉及0字节数据包的问题。 我将尝试在明天就该主题与您回圈。

[引用用户="Ralph Jacobi"]

[引用 user="Brian Willoughby"] USB 库或 USB 外设是否可能未正确报告0字节数据包？

我需要查看我是否可以跟踪我帮助解决的有关此类数据包的问题、我不记得报告/响应是否失败、 但我不太清楚的是、在过去几个月中、论坛上出现了一个涉及0字节数据包的问题。 我将尝试在明天就该主题与您回圈。

[/报价]

发布此问题后、我返回到我的固件并更改了代码以检查回调中是否存在0字节数据包。 USB 库似乎报告了很多这样的内容、所以它不会完全损坏。 我需要做一些测量来查看0字节数据包的数量是否符合预期、我还想调查0字节数据包和损坏的数据包数据之间的时序是否存在某种相关性。 有一点、只要 USB 回调指示0字节、我就会重复使用相同的缓冲区、因为我希望队列中的有用数据已满、 也许连续两次注册同一地址可能会有问题-这可能会导致问题、但这是我在等待更多信息时可以检查的问题。

[引用用户="Ralph Jacobi"]

出现的另一个问题涉及 USBHCPDPipeWrite API。 有关详细信息和正确的解决方案、请参阅以下文章： e2e.ti.com/.../2131893

[/报价]

谢谢你。 我将对此进行研究。 但是，由于我的端点都只在中，所以我永远不会在固件中调用 USBHCPDPipeWrite()。 我进行了快速搜索、但它似乎没有被使用。 但仍然值得阅读该帖子、看看是否有其他相关方面。

[引用用户="Ralph Jacobi"]您计划进行的调查的最新结果是什么？

我看了一下 USBHCPepeRad()，它似乎有与针对 USBHCPepeWrite()报告的问题相似的问题。

因此，我认为我有几项任务：

a) UDMA 选项似乎没有这个问题、至少对于 USBHCPDPipeWrite()情况是如此。 我应该尝试打开 UDMA 以查看这是否解决了我的问题。

b)如果 uDMA 不能解决问题、那么我需要完成对 USBHCPDPipeRead ()中代码的检查、并尝试进行更改以解决问题、但是...

c)由于我是对照2.1.0.12573版的库进行编译、我觉得在对库进行任何更改之前、我真的应该升级到2.1.4.178。 问题在于、当我将所有库切换到2.1.4 (包括 usblib)时、我的 TM4C 固件会在连接 USB 设备时停止识别它。 可能需要进行一些重要的调试、以弄清为什么我的固件在2.1.0下工作正常(损坏的数据除外、这对于两个版本都是常见的)、但看不到我的 USB 器件在2.1.4下工作

2.1.0与2.1.4之间是否存在任何可能解释(C)的已知问题？ 我实际上没有看到任何发行说明。 我同时安装了2.1.0和2.1.4。

[引用 user="Ralph Jacobi">我找到了我曾调用过的帖子、但我不确定该帖子是否适用于您的情况： e2e.ti.com/.../2279503

我发现该线程特别令人困惑、因此我无法完全理解它。 但是、关键点似乎是设计中预期可变数据包大小的意外0字节数据包、并且可能是 USB 事务中的一些错误。 通过更改固件设计似乎可以清除错误、但我不确定。

在本例中、数据包大小不可变。 端点上总是386字节、标记为388字节长度(这样、当数据包大小与端点大小完全匹配时、避免了数据包继续的预期-在 Mac OS X 下操作 USB 设备时我学到了很多、这种情况下的 USB 实现非常出色)。 由于器件数据包速率为976.5625Hz、而 USB 主机帧速率的标称值为1000Hz、因此预计会出现0字节数据包、并且每侧(主机与器件)都具有不同的晶振时钟源。 预计某些帧将没有数据就绪。 更重要的是、Total Phase Beagle USB 分析器根本不会报告任何 USB 事务错误、甚至不会接近0字节端点事务。 USB 通信似乎完全按预期进行、没有任何错误。

感谢您指出另一个主题。 看起来我需要在其他地方进行调查。

[引用用户="Brian Willoughby">是否有任何与2.1.0和2.1.4相关的已知问题可以解释上述(C)？ 我实际上没有看到任何发行说明。 我同时安装了2.1.0和2.1.4。[/报价]

我在安装目录的单独 PDF (SPMU299E)中找到了发行说明。 事实上、我已经下载了 PDF、它在我拥有的112个其他德州仪器文件中丢失了。

发行说明中似乎有很多信息、可能还有一些部分可以帮助我成功地从2.1.0移植到2.1.4 -然后我可以查看自己对库进行的改进。

[引用用户="Ralph Jacobi"]您计划进行的调查的最新结果是什么？

更新：仔细检查 Beagle USB 分析器捕获的数据后、我发现两个端点实际上都存在数据错误。 因此、我的线程的标题现在在技术上是不准确的。 EP1中的数据损坏足够大、无法轻松检测、但 EP2上的损坏恰好在正常数据范围内、但仍然不正确。

我想澄清一点、EP1和 EP2之间似乎没有明显的区别。 它也不像 EP2那样完美。

继续研究...

更深入地看、我看到我使用的是 uDMA。 受 USB_host_audio_in 示例的启发、我的固件调用 USBHCDipe_isoc_in_dma (0、USBHCD_pipe_isoc_in_dma、...) 然后使用 USBHCPDPipeSchedule()请求将数据写入所需的队列。 通过在每次回调中再次调用 USBHCPIPPESchedule()来保持等时流。

这似乎避免了在 USBHCPIPEREAD()中进行特殊的64字节大小处理。
据我所见、uDMA 应在一次传输中加载所有386个字节、但我看到的是损坏的字节。
有什么提示说明了为什么通过 UDMA 的等时传输会受到数据损坏的影响？

您好 Brian、

感谢大家分享 UDMA、我深入了解了这一点、但仍未找到具体的内容。 我正在与另一位 USB 专家讨论这一问题、我们希望了解腐败的观察位置。 损坏是否仅发生在 TM4C 存储的缓冲器中的 TM4C 侧？ 这是我对如何解读讨论的理解、但我看不到讨论内容有明确的表述。。。

[引用 USER="Ralph Jacobi">我正在与另一位 USB 专家讨论这一问题、我们希望了解腐败在何处发生。 损坏是否仅发生在 TM4C 存储的缓冲器中的 TM4C 侧？ 这是我对如何解读讨论的理解、但我没有看到讨论明确表述...

不确定我是否确切地理解了问题、但我使用了 USB 分析仪来确认线路上的数据是否正确、并且仅在 TM4C 存储器空间内损坏。 我不知道有什么方法可以检查 USB 外设本身中的数据。 尽管没有报告 USB 数据包校验和错误、但 USBHCPDPipeSchedule()例程会获取我提供的地址、并且我会看到写入该地址的数据损坏。 我将在完成回调期间尽早检查数据。 我将队列移动到 SRAM 的单独部分、只是为了确认它不是来自其他代码的随机存储器损坏(没有太多其他代码)。 我的队列有足够的空间容纳4个数据包、但我也使其足够大、可以容纳40个数据包、结果相同。

正如我提到过的、它可能与由于器件和主机之间的时钟不匹配而需要定期生成的0长度数据包有某种相关性。

供参考：我简单地尝试将 USBHCD_pipe_isoc_in_dma 的 USBHDPipeAllocSize()参数更改为 USBHCD_pipe_isoc_in、假设这会禁用 UDMA、但它没有效果。 我看到、如果库代码无法分配 DMA 通道、那么它确实会返回到非 UDMA 操作、因此也许我应该确认它实际上是在使用 UDMA。

您好 Brian、

谢谢您、尽管我对我的问题有点不清楚、但这对我们的问题回答得很好。

最近发现了一个针对 usbdma 的错误、同时解决了针对 PipeWrite 问题构建更强大的解决方案的问题。 我要附上涵盖这两个修复的文件。 请使用这些文件更新您的 usblib (如果将.lib 链接到您的项目、请确保重新编译 usblib 本身)并查看是否有任何改进。

如果与0字节数据包相关、则计时应在点对齐、而不仅仅是在附近。 您如何计算需要0字节数据包时的41-42帧？ 您是否测量到0字节数据包在计算中完全符合预期？ 如果0字节数据包确实位于41-42帧标记处、并且错误发生在45-49帧范围内、则我们不认为存在任何相关性、因为该差异太宽而无法解释。

您提到 TMS320使用自定义类、这与音频设备有何不同？ 虽然在这方面没有发现问题、但或许更好地了解器件的设置方式也可以帮助我们。

usbdma 文件： e2e.ti.com/.../usbdma.c

usbhostenum 文件： e2e.ti.com/.../1541.usbhostenum.c

[引用 USER="Ralph Jacobi]usbdma 最近发现了一个错误、同时解决了针对 PipeWrite 问题也构建了一个更强大的解决方案。 我要附上涵盖这两个修复的文件。 请使用这些文件更新您的 usblib (如果将.lib 链接到您的项目、请确保重新编译 usblib 本身)、并查看是否有任何改进。

这些修复确实改善了情况、但未完全解决问题。 感谢您提供这些文件、我很抱歉在您回来之前延迟了很长时间。

在数据路径与 macOS USB 主机一样可靠之前、似乎仍然需要进一步的工作。 我偶然看到了您提供的文件中的更改、但我没有完全检查它们是否存在其他错误。

[引用]如果与0字节数据包相关、则计时应在点对齐、而不仅仅是在附近。 您如何计算需要0字节数据包时的41-42帧？ 您是否测量到0字节数据包在计算中完全符合预期？ 如果0字节数据包确实位于41-42帧标记处、并且错误发生在45-49帧范围内、则我们不认为存在任何关联、因为该差异太宽而无法解释。[/引述]

我在一段时间内没有测量误差、当然也没有使用新代码。 如果您认为这将有助于缩小修复范围、我一定会查看。

通过将976.5625帧/秒的数据生成速率与1000帧/秒的 USB 速率进行比较、以数学方式计算了41-42帧。 我估计在42.666帧时、该帧结束时不会有数据。 当然、0字节数据包的确切速率取决于 USB 器件上的晶体与 TM4C 主机之间的差异以及中断的时序。

另一个细节是 USB 设备有两个端点、每个端点以976.5625Hz 的速率生成数据包。 因此、每个 USB 帧通常有两个等时数据包、但每次输入(41或42个数据包)、USB 帧只在一个端点数据包中有数据、而另一个端点有一个0字节数据包。 使用 Total Phase USB 分析仪长时间运行后、我从未看到任何包含两个0字节数据包的 USB 帧。 在 USB 帧的周期内、可能略小于1ms、USB 设备始终至少产生一个非零数据包。

发生的情况是、每41或42个周期、一个端点就会产生一个0字节的数据包。 然后、在一定数量的帧之后、另一个端点将产生一个0字节的数据包、两个端点将返回相同的序列号。 有时、两个端点会在连续的 USB 帧上丢失一个数据包、但实际上这种情况很少见。 更常见的情况是、在另一个端点跳过数据包之前、它可能是1、3、6、8、11或12帧。 后一种影响可以解释为什么我看到错误之间有45-49个帧。 我想它毕竟可能与0字节数据包相关。

[引述]您提到 TMS320使用自定义类、这与音频设备有何不同？ 虽然在这方面没有发现问题、但或许更好地了解器件的设置方式也可以帮助我们解决问题。

我想说、它与 USB 音频类器件有很大不同、因为描述符完全不同、数据包为384字节或0字节。 但从它具有等时端点的意义上讲，USB 自定义类设备最接近音频或视频设备，或者可能是 USB ISDN 电话终端。 与 USB 音频类器件的一个大区别是、音频具有基于采样率的标称数据包大小、并且时钟之间的差异仅会因来自所有通道的一组采样的大小而变化。 对于立体声、16位音频器件、数据包大小只会相差4字节。 对于8通道24位音频器件、数据包大小会相差24字节、但这不足以将数据包大小一直降至0字节。 TMS320音频设备可能最靠近 USB 麦克风、USB 麦克风只有等时输入端点、但没有输出端点。 除了具有较大的数据包大小变化而不是相对较小的数据包大小变化之外、这可能是最接近的示例。 我的 TM4C 固件确实是以 USB 麦克风示例开始、然后更改了代码以适应定制类。