您好，
我目前正在使用USB处理产品，并且在枚举时遇到一些问题。
最近，我已将USB库从v135更新到v151。 这有助于降低故障率，但导致了新的问题。 库源v135最初是在本地复制的，并修改了文件，将USB函数重新定位到“从ram运行”部分。 要使用v151以更简洁的方式执行此操作，我现在更愿意将.lib文件直接链接到项目，以方便将来的更新。 这样做会导致USB功能不再存在于RAM中，并且USB库的内存占用空间似乎是其容量的3倍...因此我无法再将其全部置于RAM中...
最初我认为链接器错误地包含了未使用的内容。 有关详细信息，请参见此线程。 在George Mock的帮助下，我确定了与主机模式功能相关的模块似乎包含在最终二进制输出中，而我只打算执行设备模式操作。 以下是在不尝试重定位到ram时对某些.map内容的分析：
我知道我的前任已经通过从RAM运行库解决了与我所遇到的问题类似的问题。 请参阅此处。 所以我真的需要能够做到这一点(引导加载也需要更长的时间... ：/)
如何配置库或修改代码，使与主机相关的功能和任何其他不需要的模块不包括在二进制输出中？
*对于USB低层协议，哪些模块最重要，如果我不能像以前那样完全安装，最好将其重新定位到RAM中？ (我想重新定位第一个usbdenum.obj和usbdhandler.obj)
目前，我的项目的最后一个版本使用库v151，该库作为.lib包含在闪存中(甚至是中断处理程序)。 经过大约40个主机重新引导周期(未关闭设备电源)后，产品在枚举时发生故障。 该器件基于TMS320F2.8062万，主机是Windows 10计算机。 我已经注意到，在这个过程中，来自USB的5V电压不会下降，因此我无法根据这个事件重置USB堆栈，而在“挂起事件”中，除了刷新缓冲区之外，还会执行更多操作，这似乎很危险...
我的实施基于“TivaWare
USB库用户指南”中所述的使用通用批量设备类的方法(第 2.5 ．2)，并且靠近控制套件中的相关示例项目(USB_DEP_BULK)。 如果 有人对如何消除这种情况有任何其他想法或线索，请告诉我。
