Thread 中讨论的其他器件:EK-TM4C1294XL
我正在使用 TM4C1242的 USB 主机模式来访问拇指驱动器、除了在 USB R/W 期间移除驱动器时、它将挂起到 USBHCPpeWrite 等阻塞 API 中、因为 R/W 将由于移除拇指驱动器而无法完成。
是否有人已经解决了此问题? 我希望 USB 堆栈会使用错误代码停止 R/W、并等待 USB 拇指驱动器重新连接
谢谢!
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.
我正在使用 TM4C1242的 USB 主机模式来访问拇指驱动器、除了在 USB R/W 期间移除驱动器时、它将挂起到 USBHCPpeWrite 等阻塞 API 中、因为 R/W 将由于移除拇指驱动器而无法完成。
是否有人已经解决了此问题? 我希望 USB 堆栈会使用错误代码停止 R/W、并等待 USB 拇指驱动器重新连接
谢谢!
尊敬的 David:
这看起来 仍然与 USBHCSDPipeWrite API 相关、但与我之前提到的问题无关。 我从 fatfs 第三方库跟踪了根本原因、其中 far_usbmsc.c 中的 disk_write API 使用对 USBHMSCBlockWrite 的调用。 通过 USB 堆栈进行的跟踪表明、它调用 USBHSCSIWrite10、然后调用 USBHSCSISendCommand、 最后调用 USBHCSDPIPEWrite。
在 USBHCPDPIPEWrite 内部、对断开事件进行了检查、如下所示:
if (g_sUSBHCD.ui32IntEvents &(INT_EVENT_DISCONNECT |) INT_EVENT_VBUS_ERR | INT_EVENT_POWER_FAULT))
当接收到 INT_EVENT_DISCONNECT 和 INT_EVENT_SOF 的结果等于0x14时、此检查由于某种原因失败。
它看起来可能与 将 g_sUSBHCD 结构声明为静态相关。 我发现的另一篇文章建议将 g_sUSBHCD 变为易失性文件、这样可以解决用户问题。 不幸的是、在我的结尾、似乎没有这样做、但我希望您尝试一下、如果您在这方面有任何改进、我会向您报告。
我将在明天继续对此进行调查。
尊敬的 David:
很抱歉耽误你的时间。
看起来问题实际上是由编译器而不是源代码引起的。 您使用的是哪个版本的 CCS + ARM 编译器?
当我将示例和 usblib 移入 CCS V8并使用18.1.0.LTS 编译器在 V8内构建时(请注意、您必须为此重新链接库)、问题不再存在。
我们不知道编译器导致此问题的原因、但随着最新的 CCS+ARM 编译器解决了此问题、我们目前不打算与 CCS 团队进一步探讨此问题。 更新最新的 CCS+ARM 编译器是否适合您的情况?