[参考译文] TM4C1294KCPDT：是否访问/下载较旧的 TivaWare 版本？

您好 Brian、

  12573后 USB 中的几处更改、但 USB +Vbus 检测寄存器中的更改不正确。  当 USB 电缆被插入/拔出时、请检查调试寄存器中的这个+Vbus 位切换。 如果您真的需要、我有12573个字符、请记住、它是在后续版本中更改的 USB 数据整数字符类型。

我的应用仅在 USB 主机模式下具有 TM4C、因此我假设+Vbus 检测不适用。

是否有任何会影响 USB 主机模式的 Tiva USB 库更改？

请注意、USB_host_msc 示例在我的自定义硬件上运行正常、插入的 USB 记忆棒的检测工作正常。 当然、此示例与版本号匹配、而我的固件使用的是旧库、我假设我需要进行一些更改才能使其使用更新的库版本。

顺便说一下、我的应用需要检测 USB_class_vend_specific 器件。

[引用 user="Brian Willoughby"]因此我假设+Vbus 检测不适用。

ID 引脚有时不被使用、例如在 ICDI 上、 它不知道 GTO 是否是电源、讨厌它！

因此、 您的+Vbus 在主机模式下为 USB 器  件供电、但必须启用 PQ4才能输出使能 U4 TPS2052、从而将+5V 电压切换到 GTO 端口。 请回想一下 EK-TM4C1294XL、USB 主机通过 GPIO PQ4端口配置启用  、默认为开漏、从 GTO 器件模式默认为+Vbus 输入时禁用+5V。

我使用 TPS2051更改了一些内容、并将 USB0EPEN 放置在 PA6 (引脚40)而非 PD6上。 我修改了源代码以反映这些更改、正如我提到过的、USB 记忆棒主机固件工作正常。 我测试的记忆棒(恰好是德州仪器(TI)会议上的品牌！) 亮起以显示它正在接收电源、当然、访问命令也可以正常工作。

我还将电源默认检测信号移至 PA7、从而允许启用硬件外设电源故障输入引脚功能 USB0PFLT。 这是对 EK-TM4C1294XL 参考电路的改进、因为该参考电路在 PQ4上使用通用 GPIO、这在某种程度上是有原因的。 我调整了源、以反映此官方引脚的使用情况。

问题似乎在于、我的注册 USB_class_vend_specific 驱动程序从未被调用、但在移除另一个 USB 测试设备时、事件驱动程序被正确调用。 我可能需要找到 usblib 源代码并将其编译到我的固件中、以便我可以调试上游函数。 目前、我正在链接预编译的 usblib、因此我无法轻松调试为什么不调用我的驱动程序。

请注意、EK-TM4C1294XL 平台上的行为相同、由于引脚不同、因此对固件源进行了适当的更改。 两年前、该固件识别出了我的 USB_class_vend_specific 器件、使用适配器电缆将 EK 上的 USB Micro-B 插孔与标准器件电缆所需的 USB A 插孔配合使用。 当时我没有定制硬件平台、但现在使用新的 CCS 和新的 Tiva USB 库构建时、固件在 EK 上停止工作。 我希望我保存了一个旧的编译、因为查看旧的二进制文件是否仍然起作用会很有用。

我使用 USB_host_msc 示例进行测试的部分原因是为了确认我的自定义硬件平台和参考 EK-TM4C1294XL 之间没有意外差异。 到目前为止、我还没有看到任何特定于我的硬件的故障(即 USB_host_msc 在这两个硬件上都能正常工作、但我的 USB_class_vend_specific 驱动程序在两年前的 EK 上都能正常工作)。

[引用 user ="Brian Willoughby"]我还将电源默认检测信号移至 PA7，允许启用硬件外设电源故障输入引脚功能 USB0PFLT。

 对定制 PCB 布局进行了相同的更改、但 在发生 USB0PFLT 故障时无法测试 USBOPEN 是否实际禁用。 根据     数据表中引脚功能的有限文本假定 UB0PFLT、USB0OPEN 似乎可能会自动禁用。   我们的电路布局示例 可能有助于比较我们对该函数的看法是否相似。 我们的想法是允许 主机模式 或与 EK 类似的器件模式、但启用 USB 的 TPS 和 PQ4电源故障功能。  

[引用 user="Brian Willoughby"]两年前，该固件识别出了我的 USB_class_vend_specific 设备，

如果启用了 Windows 7驱动器保护、则可以回滚相同的项目目录、但请确保先将文件夹复制到安全位置。

[引用 user="Brian Willoughby"]问题似乎是我的注册 USB_class_vend_specific 驱动程序从未调用过，

可能 的 USBID 中断会触发对 主机模式支持模块中功能的调用、并且不 会出于任何原因触发中断。 请务必查看 TM4C1294NCPDT 勘误表、了解 UB0外设中可能导致 您怀疑的问题。   回想一下、在主机模式支持中、需要使用 USBID 和 R74来限制电流。 在 设备模式下调用  您可以将 USB 连接的方法类型更改为强制或选中、并为其他测试连接模式的方法定义存在。 希望这对您有所帮助：)

[引用 user="BP101]]对 定制 PCB 布局进行了相同的更改、但在 发生 USB0PFLT 故障时无法测试 USBOPEN 是否实际禁用。 根据     数据表中引脚功能的有限文本假定 UB0PFLT、USB0OPEN 似乎可能会自动禁用。   我们的电路布局示例 可能有助于比较我们对该函数的看法是否相似。 我们的想法是允许 主机模式 或与 EK 类似的器件模式、但启用 USB 的 TPS 和 PQ4电源故障功能。[/quot]

请注意，对 USBHCDPowerConfigInit()的调用采用了一些位字段，这些位字段似乎允许在 USB0PFLT 变为低电平或高电平时采取措施禁用 USB0EPEN。 我们可能使用的大多数芯片似乎都是低电平有效、这通过正确的位字段很容易得到支持。 我没有查阅过文献资料来源，以确认这项工作是否有效。 我对更改示例的简短测试似乎使事情功能变差、因此我需要进行更多调查。

USBHCDPowerConfigInit (0、USBHCD_VBUS_AUTO_HIGH | USBHCD_VBUS_FILTER | USBHCD_FAULT_LOW | USBHCD_FAULT_VBUS_DIS)； 

[引用 user="BP101]USBID  中断可能会触发 对主机模式支持模块中功能的调用、并且不 会出于任何原因触发中断。 请务必查看 TM4C1294NCPDT 勘误表、了解 UB0外设中可能导致 您怀疑的问题。   回想一下、在主机模式支持中、需要使用 USBID 和 R74来限制电流。 在 设备模式下调用  您可以将 USB 连接的方法类型更改为强制或选中、并为其他测试连接模式的方法定义存在。 希望这对您有所帮助：)

我在此担心的是、固件以前在 LaunchPad 上工作、但现在不工作、因此似乎可以从问题中删除我的硬件更改。 任何更改都会破坏两个硬件平台的代码。

请注意、我确实向 LaunchPad 上的 VBUS 线路添加了一个电容器、以防止德州仪器已知的闩锁问题。 这可能是您提到的电流限制问题、也可能是其他问题。

我将阅读最新的勘误表、然后代码在单步执行操作时查看 usblib 源。

[引用用户="Brian Willoughby"]我在这里的问题是固件以前在 LaunchPad 上工作、但现在没有工作、因此似乎可以从问题中删除我的硬件更改。

只要一切都是完全相同的电缆等、就可能需要就 ID 引脚周围的某种库问题达成一致。 如果 ID 位在 USB 电缆热插拔时改变状态、则在调试寄存器中验证不会有任何问题。  

由于 USB0PFAULT 配置的支持、如果有一天要将其包含在主机集线器应用中、就必须将其包含在主机集线器应用中。 目前正在将 USB0用于 器件模式并希望通过端口 GCv2 GUI、 TI 删除 了对目标的所需 JTAG 控制。  如果 您愿意、我可以为您提供原始 zip 文件 v12573。

[引用 user="BP101]]只要一切都是完全相同的电缆等、就必须就 ID 引脚周围的某种库问题达成一致。 如果 ID 位在 USB 电缆热插拔时改变状态、则在调试寄存器中验证不会有任何问题。

我假设只有在使用 OTG 模式时才需要 ID 位。 对于强制主机模式、我希望 ID 位被忽略。

此外、USB_host_msc 示例在我的硬件和 EK 上运行、因此无论需要什么检测、都可以在两个位置工作。 我怀疑我的问题可能与供应商定制类有关。

[引用 user="BP101"]如果您愿意，我可以给您提供原始 zip 文件 v12573。

我找到了 v12573的备份、因此我不需要该备份。 很高兴知道 TI 是否有用于旧版本的下载页面-这对于某些项目而言可能非常重要。

[引用 user="Brian Willoughby"]对于强制主机模式，我希望 ID 位被忽略。

问题似乎仍然存在   、即上游主机驱动程序函数服务例程如何知道器件已插入 USB 主机端口。

祝您一切顺利！

您好、Charles、
这是 Brian 的请求、而不是我的请求。

您好、BP101、Brian、
好的。 如果您必须检索旧版本、请告知我。 如您所知、建议开发最新版本的问题/已修复勘误表、但我可以理解、某些工具/库版本的某些开发已冻结。

供参考、上周我回到使用了2年的固件源代码、并与旧的 TivaWare 库链接在一起、一切都正常。 这告诉我、新编译器不是问题、新的 Code Composer Studio 也不是问题。 当我用最新版本替换旧的 TivaWare 库时、东西停止工作。 这强烈表明库中的某些内容发生了变化、但我需要对所有内容进行仔细检查。

遗憾的是、我的新固件源不是通过链接到旧库而进行的神奇修复、因此我需要做一些检测工作来缩小原因范围。 我的计划是缓慢地将新源引入正在工作的旧源、直到我发现我的更改甚至阻止旧库工作。 同时，我也会再次检查是否正确地交换了旧的和新的库，因为似乎有如此多的不起作用的组合。

[引用用户="Brian Willoughby"]我的计划是将新源缓慢引入正在工作的旧源，直到我发现我的更改使旧库无法工作。

感受您的痛苦-但您使用"kiss"进行系统测试和观察-注册为识别和修复的"最佳和最快"方法。

相信(许多)在这里同样"有罪"、不是"为未来和/或意外需求做好充分准备"。   您的困境和逻辑攻击促使人们开始需要这种"防御性环境捕获和保存"。    即使在您和我"确定"的情况下、我们也不会再次需要此代码/环境！

虽然我同意"缓慢"的介绍-但始终有"更快的识别和解决"的愿望。   

当然、您已经考虑(可能)通过首先"隔离然后探测"那些规模最大/经常出现的程序元素并共享某些"常见"元素来加快/简化此分辨率！    如果这些"通过"-您的进一步"探测/测试"在尺寸/范围上有所缩小-这将加快/简化/增强您的成功之路。

另一种"通过代码缩减实现诊断加速"方法已证明成功、您可以看到"系统移除和/或绕过各个 MCU 外设-以及任何/所有相关程序"调用"。    当您的问题被简化为单个 MCU 外设时-通常-解决方案会快速遵循！

祝您好运...  

供参考、第2部分：我能够将我的新源代码合并到旧源代码中、现在它正在工作。 我使用 subversion 从旧代码创建分支、然后只有几次合并才能将其转发。 当我发现执行了"合并重新集成"以将分支拉回到中继线时、我看到唯一真正的区别是项目文件中的差异。

由于项目文件很难解密、因此我没有花时间发现导致我的问题的设置。

好消息是、我的最新代码正在使用2.1.0库版本。

坏消息是、我仍然无法在最新的2.1.4库版本中使用代码。 USB 堆栈中似乎仍然存在某种无法与我的固件和硬件配合使用的变化。

我的计划是继续使用2.1.0、直到遇到只能通过升级到2.1.4来修复的错误、尽管我不知道如何找到必要的更改。 也许我会很幸运。