[参考译文] USB 堆栈 VBUS/ID INT58 NDA

良好的项目符号校验测试、在(startup_ccs.c)中禁用 USB0_INT58注册。 如果 USB 端口被插入主机、MCU 循环 POR 周期、否则完成 POR、并且在未插入时等待端点连接状态。 无论是否已注册，都不会调用 USB0DeviceIntHandler()。 当示例软件存在中断处理问题时、NDA 会有很多内容。

软件似乎不需要清除(INT58)、因为它已经被热接线直接连接到 USB 控制器外设、谁知道。 用于检查 USB0中断状态事件的批量器件库调用永远不会在 USBDeviceIntHandlerInternal()内部得到处理。 USB0器件客户端事件状态必须通过 USB 库层进行筛选、因此状态中断不能由(USB_dev_bulk.c)处理！ 批量器件示例如何通过显示处理批量器件客户端中断状态事件的正确方法来帮助社区加快上市速度？

您好 BP101、

虽然我无法说我已经完全掌握了手头的问题、但我可以评论"INT58"、又称 USB 中断。 器件内只有一个 USB 中断、它是 INT 58 (矢量编号)/INT 42 (实际中断编号)。 因此、不起作用的想法是错误的、如果它不起作用、USB 将不适用于我们的任何 TivaWare 示例、我们将拥有一个无用的外设。

如前所述、我不清楚您看到的具体问题是什么、但 USB 中断毫无问题地工作、我们的示例显示这与您的说法相反。 关于可用性示例、 我们有很多客户从批量示例开始将产品投入市场、并在其基础上构建定制应用、而无需修改 USB 堆栈的任何部分即可证明其工作方式 器件快速推向市场所需的所有功能。

也许您上周尝试的 USB 库变色导致了这一最新问题、您可能希望恢复、看看您是否仍然观察到同样的情况。 帮助您调试系统设置的想法。

您好、Ralph、

也许在袖带外看起来都适合于散装设备的搬运、请仔细观察并进行几次您自己的测试。

[引用 USER="Ralph Jacobi"]它是 INT 58 (矢量编号)/INT 42 (实际中断编号)。[/引用]

实际上、42是调试寄存器中的位数、而不是 Tivaware (hw_ints.h) 寄存 矢量58。

[引用 user="Ralph Jacobi"]有关示例的有用性， 我们有很多客户从批量示例开始将产品投入市场、并在其基础上构建定制应用、而无需修改 USB 堆栈的任何部分即可证明其工作方式 产品快速推向市场所需的所有功能。[/quot]

 挂起清除 (INT58)是我的补丁、没有执行任何操作来清除寄存(startup_ccs.c)中断和 从未发生的处理。 USB0 不是 已注册的信标中断 、必须在进入下面的矢量中断处理程序例程时清除。 如果 USB0大容量器件应该使用信标或 GPTM 计时器 来调用 INT58矢量、在哪里/如何配置？

编辑：即使 INT 状态已清除多次、USB 重置也会循环多次插入电缆。 这种行为使 INT58看起来被应用程序忽略。  

因此、根据 Foot 注释 (HW_USB.h) 、下面的调用(USB.c)也被错误配置为强制 VBUS/ID 引脚为高电平(0x3) 0x3是调用 StackModeSet (0、eUSBModeForceDevice、0)。

针对器件模式设置(USB0_O_GPCS = 0x1)的适当引脚状态不会强制 VBUS/ID 为高电平。 否则、如果不正确、则需要更正十六进制解码的脚注(HW_USB.h)。

//
//
//！ 将 USB 控制器的模式更改为设备。
//！
//！ \param ui32Base 指定 USB 模块基址。
//！
//！ 此函数将 USB 控制器的模式更改为器件模式。
//！
//！ 注意此函数只能在支持
//！ OTG 操作。
//！
//！ \无返回。
////
*****************
void
USBDevMode (uint32_t ui32Base)
｛
//
//检查参数。
//
断言(ui32Base == USB0_BASE)；

//
//将 USB 控制器模式设置为设备。
//
HWREGB (ui32Base + USB_O_GPC)= USB_GPCS_DEVMOD；

//USB_GPCS_DEVMODOTG | USB_GPCS_DEVMOD；
｝ 

您好 BP101、

也许这些信息将有助于：

当在 OTG 模式下使用时、USB0VBUS 和 USB0ID 不需要任何配置、因为 它们是 USB 控制器的专用引脚、并且直接连接到 USB 连接器的 VBUS 和 ID 信号。 如果 USB 控制器用作专用主机或设备、 USB 通用控制和状态(USBGPCS)寄存  器的 DEVMOD 域可用于将 USB0VBUS 和/或 USB0ID 输入内部连接到固定电平、释放 PB0和 PB1管脚供 GPIO 使用。 为了使自供电设备正常运行、仍必须对 VBUS 值进行监控 、以确保主机移除 VBUS 时、自供电设备会禁用 D+/D-上拉 电阻器。

另请注意、只有在 OTG 模式下才应调用 USBDevMode API。

我同意对 hw_usb.h 脚注的评论有点不清楚、因为这些评论实际上没有太多的描述：

#define USB_GPCS_DEVMODOTG 0x00000002 //启用设备模式
#define USB_GPCS_DEVMOD 0x00000001 //设备模式 

不过、我认为不需要您进行修改、因为这些设置适用于 OTG、如果您不使用 OTG 操作、那么正如 API 所说、您不应该使用它。

[引用 USER="Ralph Jacobi"]有关如何在 USB0DeviceIntHandler 中检查中断的问题，您是否继续从项目中取消.lib 文件的链接，以及在 driverlib 和 usblib 文件夹中进行链接，以允许项目实际编译并提供对诸如 usb.c 和 usbdenum.c 等文件的调试访问？

USB 库文件 导入到 CCS 工程文件夹中、并 将其用作编译依赖项、并设置了库/路径。  然而，中断向量被编码为访问 USB0DeviceIntHandler()，而这种情况从未发生。 如果 器  件断开事件(0x004 USBIS)或恢复状态检查发生 USB0_INT58、则会出现几条 UARTprintf 消息、但从不会出现。 大容量器件 的复合 驱动程序配置 在    首次由调用方 INT58处理之前、似乎不取代或控制硬件中断或清除状态。 奇怪   的是、如果我将 INT58视为来自5ms GPTM 间隔的信标 SW 触发器、则不会发生任何不同的情况。 似乎与 INT58保持一致的中断源不能用作典型的 NVIC 控制的中断源、或者从未如此。

下面 是  EP1随机关闭的 USB 分析器点的结果。 回放 日志文件 4 (批量流1)表示我断开 电缆几次以重新启动 随机代码0x5事件的连接。

/cfs-file/__key/communityserver-discussions-components-files/908/Generic-Bulk-Device_2400_190312_2400_004.zip

您好 BP101：

这些日志文件应使用什么查看器？ 我下载了 Device Monitoring Studio、但它不会打开日志文件、查看当前版本的 DMS 需要.dmslog7文件、但这些文件是.dmslog 文件。

您好、Ralph、

日志实际上没有显示任何内容、但主机没有响应最后一个200字节的请求、即0xC000.0005常见故障代码。 OUT (向上) 端管道 无法发送请求的数据包、因为它会突然 中止管道。  有时 、怀疑电气干扰 更严重、但在   AHB 活动较高的其他时间、OUT 端管道永远不会中止和频繁间歇中止。 如果我恰好重新连接 USB、则 OUT 端管道在中止之前会长时间(几分钟)保持连接。  如果 NVIC 与 PWM0挂起时不忙、则 OUT 端管道保持连接数小时、很少中止、但检测到中止时不会如此。

真正的问题仍然是 INT58矢量如何 不调用 已注册的处理程序 并检查(usbdenum.c)中配置的 USBIS 状态标志？ 大容量器件驱动程序(usbdenum.c)似乎源自 TM4C123 MCU、 稍后 进行了调整以与 TM4C1294配合使用。

看起来(usbdenum.c)对这种奇怪的行为非常可疑、尤其是因为没有  调用已注册的 INT58矢量处理程序。  也许  INT58处理程序 已经被调用了两次、一次是以前调用过、一次是在 USB 库中的某个位置注册、 一次是在堆栈中更高的位置？  INT58矢量似乎 处理电缆连接、但不与  (startup_ccs.c)中的寄存矢量调用进行通信。  这意味 着 INT58硬接线到 USB0、或者向量处理程序调用被 USB 控制器自动解除挂起。    如果设计人员不知道信号量中断、就无法在 AHB 上运行它们！    如果 USB0需要信号量中断处理、则应在数据表中注明、无需 NDA。

/cfs-file/__key/communityserver-discussions-components-files/908/usb_2D00_monitor5.2.zip

BTW：日志播放(底视图选择)需要选择 URB +其他基准标记选项。 左上方的下拉框选择连续或日志加载播放步骤需要很长时间。 但是、请订购 CTRL+TAB 以在视图窗格之间切换、没有工具栏图标。 第一次尝试5.2后无法运行 Studio、很难浏览屏幕。 很明显、我们换了5.2、并努力捕捉非常奇怪的导航技术。