[参考译文] TM4C1294KCPDT：USB0 OTG 器件挂起 VBUS 引脚

您好 BP101、

跟踪您通过堆栈调试描述的内容具有挑战性、您能否在 USB 端口上获取 USB 分析器、以便我们可以看到 USB 线路上发生的实际通信？ 然后、我们将能够查看是否发生了挂起以及任何可能的数据包未被正确处理。 借助这些信息、跟踪应用程序本身的任何问题变得容易得多。

您好、Ralph、

我让 ICDI 调试控制台从 USB 中断处理程序内部打印 UART 调试消息 HOT、在挂起事件、SOF 或任何其他事件期间、不会打印该消息。 我在用于确定中断硬件源的状态消息返回变量中添加了静态变量。  还没有机会对其进行测试、并使用指向电源故障状态消息的中断将三条 RX 事件消息分开。 这并不奇怪、即使配置了自供电器件、也会监控 VBUS 引脚的电流。  同一中断处理程序从未在任何版本的 USB 库中正常工作！ USB 链路建议保持活动应以 1ms +/-500ns 的速率发送 SOF 帧 、而这在批量器件软件中未进行配置。  因此 、暂停/恢复 硬件中断必须填充、在我看到的3ms 总线空闲时间内保持活动空闲状态。 当 PWM0的中断优先级高于 USB0时、通常会在 PWM0过度活动期间发生这种情况！    

似乎端点空闲问题与  自供电设备相关、因为 USB 设备 客户端 传输在1秒的间隔内发生、预计挂起不会保持活动状态。 我没有 USB 分析 器来检查为什么 USB0外设没有返回或检测到中断状态、但复合事件始终传递给 RxEvent 处理程序。 由于   未知原因、硬件中断状态代码会检查控制 EP0状态两次、因此该代码是冗余的。

批量中断处理程序代码 snips：注意 ui32Status EP0与  之前通过 USB0DeviceIntHandler()返回并通过 USBIntStausControl() (usb.c)推导出的类似状态的 EP0是冗余的...

uint32_t
USBIntStatusControl (uint32_t ui32Base)
｛
静态 uint32_t ui32Status；

//
//检查参数。
//
断言(ui32Base == USB0_BASE)；

//
//获得一般中断状态，这些位进入高8位(<<漂移发生的确切情况是什么？？？？？)
//返回值。
//
ui32Status = HWREGB (ui32Base + USB_O_IS) 

void
USBDeviceIntHandlerInternal (uint32_t ui32Index、uint32_t ui32Status)
｛
静态 uint32_t ui32SOFDivide= 0；
void *pvInstance;
uint32_t ui32DMAIntStatus；
uint32_t ui32LPMStatus；
//
//总线上发出挂起信号。
//
IF (ui32Status 和 USB_INTCTRL_SUSPEND)
｛
UARTprintf ("INT 状态 USB0暂停(usbdenum.c)\n"\})；
//
//如果指定了 SuspendHandler()，则调用它。
//
if (g_ppsDevInfo[0]->psCallbacks->pfnSuspendHandler)
｛
G_ppsDevInfo[0]->psCallbacks->pfnSuspendHandler (pvInstance)；
｝
｝

//
//总线上发出恢复信号。
//
if (ui32Status & USB_INTCTRL_RESUME)
｛
UARTprintf ("INT 状态 USB0恢复(usbdenum.c)\n")；
//
//如果指定了 ResumeHandler()，则调用它。
//
if (g_ppsDevInfo[0]->psCallbacks->pfnResumeHandler)
｛
G_ppsDevInfo[0]->psCallbacks->pfnResumeHandler (pvInstance)；
｝
｝

//
//获取控制器中断状态。
//
ui32Status = MAP_USBIntStatusEndpoint (USB0_BASE)；

//
//处理端点0中断。
//
if (ui32Status & USB_INTEP_0)
｛
USBDeviceEnumerHandler (&g_psDCDInst[0])；
ui32Status &=~USB_INTEP_0；
｝ 

重新插入 USB 电缆 以清除 EP1客户端  主机端的随机挂起事件后、USB 分析器会报告此情况   每次异常处理程序发布故障时、主机端客户端必须关闭/打开。  

您好、Ralph、

我不认为此问题与电源相关 、因为返回的事件代码 不符合任何电源定义的要求(上述文章)。  然而、在   缺少~OUT_PKTRDY 的情况下、IDLE 状态中断处理程序不会根据 USB 记录的暂停状态处理生成保持活动帧。 因此 、如果 连接主机端的挂起客户端没有自动恢复、可能会发生错误的挂起状态事件。  客户端确实会像  现在一样快速阻住并发布异常标志。  如何纠正此中断状态调用以阻止发生虚假挂起？ USB 控制器设计是否通过向  输出端点发送保持活动帧(SOF)来补偿空闲挂起错误？

否则、无论    是否 调用过 USBDCDPowerStatusSet()调用、USBDCDInfoInit()(下面的调用 snip)都将布尔自/总线电源状态标志强制为 false。  似乎 更智能的逻辑 将查询 正确的 bool 标志、而不是在   假定的应用上强制可能不正确的电源状态。     

//
//在空闲状态下，代码正在等待从主机接收数据。
//代码需要发送空帧保持活动状态，直到数据包就绪！
// USB 在总线上定期发送帧起始数据包或保持活动状态。
//这可防止空闲总线在没有数据的情况下进入挂起模式。
//•高速总线将每125.0 µs±62.5 ns 发送一次微帧。
//•全速总线将每1.000ms±500ns 发送一个帧。

案例 eUSBStateIdle：
｛
//
//是否有数据包等待我们？
//
if (ui32EPStatus & USB_DEV_EP0_OUT_PKTRDY)
｛
//
//是-处理它。
//
USBDReadAndDispatchRequest (0)；
｝
中断；
｝ 

//
//根据的标志确定自供电或总线供电状态
//用户通过调用 USBDCDPowerStatusSet()来提供；
//
G_psDCDInst[0].bPwrSrcSet = g_psDCDInst[0].bPwrSrcSet； 

 

您好 BP101、

您描述的暂停问题不是我们遇到的问题、使用 UART 输出进行调试不是我能够处理的足够数据。 您需要获取 USB 分析器并向我发送 USB 分析器捕获的 USB 线路、以便我可以看到正在识别的数据包、时序和错误字节等

一旦准备好、尝试并发现导致该行为的原因可能是您的设置的哪一部分更可行。

您好、Ralph、

但是、您可以看到、挂起中断不是从主机数据包触发的、也不是从挂起中断触发的。 您已回避我的问题 USB 2.0标准要求保持活动帧以阻止数据包空闲期间的 Rouge Suspend 事件。 空闲事件处理程序不会尝试保持 USB2.0挂起合规性。 推断 USB 库不存在保持活动 SOF 是合乎逻辑的、但为什么？ PHY 在空闲数据包传输期间是否自动产生必要的保持活动帧？

也就是说、由于 PWM 占据 NVIC 更高优先级的状态、USB 分析器不会揭示库发布 Rouge Suspend 事件的原因。 我怀疑 D+上的1.5k 上拉电阻会触发 Tivaware USB 库控制之外的 USB 外设寄存器！ 否则、发生挂起事件的唯一方法是 VBUS 引脚电流超过500mA/2、这是自供电设备的默认选择。 我删除了 VBUS/ID 引脚微型端口连接 PHY 控制、并发生相同的挂起事件。

我们必须问、如果上述挂起中断处理程序不执行、USB 外设挂起事件如何发生？ 唯一逻辑上的答案是应归咎于空闲处理程序。 其他情况下、主机可能仅通过 USB 中断向 EP1发送挂起通知、而此中断从未发生。

您好、Ralph、

在1ms 间隔内握手 USB2.0标准发送 SOF 帧、或者在空闲时间内握手器件主机、NVIC 其他外设中断。 当 NVIC 正在处理更高优先级的中断、例如 PWM0时、处理 EP0的 USB 库不会执行该函数(在 eUSBStateIdle 中为：)。

后来的挂起事件似乎由 USB0控制器触发(内部)。 它不是设备客户端主机信号"Suspend"或"Suspend"中断将在事件发生之前发生。  事实上、USB 协议分析器无法调试内部 USB0寄存器或中断。

再次发生所有其他 UARTprintf()时，打印几个挂起事件，只需插入 USB 电缆，在 PWM0运行时打印几个挂起事件。 很明显、EP0在插入或空闲期间不向器件主机发出 NAK、并且内部发生了几个挂起事件。 否则、如果之后不久没有恢复、则永远不会发生暂停事件。 您尚未解释为什么在启动 EP1设备客户端之前、在多个挂起事件之后从未发生恢复。 在端点客户端启动之前、DCD 器件驱动程序似乎也无法停止/NAK EP1。 在 PWM0高优先级中断期间、可能还会发生多个重复暂停、并插入电缆。

帧起始数据包：

由 µs 帧编号组成的 SOF 数据包由主机在全速总线上每1ms±500ns 或在高速总线上每125 µs±0.0625 μ s 发送一次。

您好 BP101、

我同意分析仪不会在内部调试、但我甚至需要这样做才能开始调查。 这个问题以前从未出现过、我也没有其他遇到过这个问题的客户的背景可供参考、因此我必须从头开始、我甚至需要 USB 分析仪数据来开始研究这个问题。 如果没有看到 USB 数据、我无法回答有关 Resume Not 跟随的问题。 这就像问我、为什么 SPI 从器件在不能对 SPI 线路进行范围控制的情况下无法响应、以查看实际发生的情况！ 我不知道数据包是否被丢弃、是否被发送、最后发出的数据包是什么等等、没有这些信息！！

在我拍摄 USB 分析器照片之前、我无法帮助您解决此问题。

您好、Ralph、

有时、答案是让我们正视于我们、并在没有解决方案的情况下向本论坛提交了两年或更长时间。  您 还应该问的是、在没有触发中断事件的情况下、如何从嵌入式 USB 库触发恢复事件。  正如我已经说过的、您 可以从 UARTprintF 中看到的几次、只需插入电缆即可暂停。 批量器件示例中始终存在这一完全相同的问题、但未打印。  TI 工程师都是无头绪的 USB 器件模式存在 OTG 电源问题、并且 Tivaware 未配置也未分别监控 USB0PEN / USB0PFLT0 (PL6/PL7)。 与数据表和 Tivaware 配置注释相反、USB 控制器对于 OTG 器件模式的运行方式有其他想法。

尽管随机管道断开条件通常发生在 内部挂起事件期间、但它不是数据传输的结果。 很明显、嵌入式 USB 库部件在初始化期间以及当 OTG 寄存器错误检测到 VBUS 电流电平时对外设作出反应。  挂起提示 的运行违反了 Tivaware 器件调用如何 控制 USBEPC、USBEPCISC、USBVDC 寄存器、或者 根本不控制。

同样、挂起问题更分类为未公开的 OTG 内部器件 勘误表。 我说勘误表、因为无论  配置了什么器件模式 VBUS/ID 引脚、发现 VBUS 引脚上有任何电容或没有电容都会更改故障频率、 并且控制描述符200mA 计数 也会增加。 由于有一 个 SW 滤波器校正、这个问题是已知的、但是 self_power_device 或 USBOTGMode 配置的 VBUS 引脚不需要这个问题。   发布了相关线索、 USB 控制器期望在 批量器件示例或声称 仅 对主机模式配置有效的 Tivaware 调用之外配置 OTG 器件(引脚/寄存器)。  

我 之前 发布了事件回调修改以发布挂起 打印、因此您可以  轻松地看到与 PIE 相同的问题。

 

您好 BP101、

我认为您需要花一些时间来回顾 USB 操作应该是如何发生的。 为 USB 设备生成主机端点并不能解决您的问题、我们肯定永远不会考虑在我们的 USB 库中添加100多个客户正在使用的这种自相矛盾的代码、而不会出现在您的系统设置中的问题。

没有"未知的默认主机端点"、因为 TivaWare USB 器件模式处理不使用主机端点。

如果您看到改进、这意味着您的配置中可能缺少另一个由主机端点配置 API 调用的 USB 设备 API 调用。 因此、我建议您检查 USBHostEndpointConfig 中执行的操作、并查看哪些操作会影响 VBUS 和 USB 电源设置、然后浏览初始化代码、确保您实际上正在进行所有必要的调用以设置正确的寄存器。

[引用用户="Ralph Jacobi"]
没有"未知的默认主机端点"、因为 TivaWare USB 器件模式处理不使用主机端点。

  当确定需要建立正确配置的控制端点0时、需要任何控制端点都是错误的。 从设备客户端连接输入/输出端管道的角度来看、它是一个主机控制消息端点、从未配置过。  同样 、在空闲总线时间内需要 NAK 帧延迟来停止 挂起发生、并且 (usbdenum.c) 因为它存在而没有被设置用来处理 高速 EP0信令的任何此类功能。

不管怎样、它没有显示 隐藏的默认控制 EP0配置、因此我认为它不存在！ 也许您应该花时间测试大容量器件示例、此示例的键盘回波信号速率大于键盘回波信号速率、这只是一个通用示例。 MCU 绑定多个共享 AHB 和更高优先级外设的点 会占用 更多的时间片、使其与 USB0脱离。 数据表不会试图建议 USB 库处理 NVIC 中断可能需要任何特定的 CPU 优先级、而不会明确修改  示例软件、从而 维持 USB2.0 消息/数据流数据包传输速率。  

[引用 USER="Ralph Jacobi"]如果您发现有改进，则表示您的配置中可能缺少另一个由主机端点配置 API[/quot]调用的 USB 设备 API 调用。

TI 工程师使用 未知的默认控制端点0配置编写了器件示例。 同意 现在已将缺失的呼叫正确配置 EP0添加到设备客户端、如上述 POST 所示！ 也许您也需要回顾一下 USB 2.0操作应该是如何发生的。  

https://en.wikipedia.org/wiki/USB#Further_reading

批量传输：使用所有剩余可用带宽的大间或传输、但不保证带宽或延迟(例如文件传输)

当主机开始数据传输时、它会发送一个令牌包 、其中包含使用(DEVICE_ADDRESS、端点编号)部分指定的端点。 如果从主机到端点的传输、主机将发送一个输出数据包(令牌包的专门化)、其中包含所需的器件地址和端点编号。 如果数据从器件传输到主机、则主机会发送 IN 数据包。 如果目的端点是单向端点、其制造商指定的方向与令牌包不匹配(例如、在令牌包为 OUT 包时制造商指定的方向为 IN)、则令牌包将被忽略。 否则、它将被接受、数据传输可以开始。 另一方面、双向端点接受输入和输出数据包。

您好 BP101、

我再次不确定您从哪里获得这些想法。

通过处理程序在 USB 堆栈内正确配置 EP0。

函数调用链为 USB0DeviceIntHandler (在 startup_ccs.c 中)-> USBDeviceIntHandlerInternal (usbdenum.c)-> USBDeviceEnumerHandler (usbdenum.c)

最后一个函数具有以下状态：

//
//数据仍在发送到主机，因此在中处理此问题
// EP0StateTx()函数。
//
案例 eUSBStateTx：
｛
USBDEP0StateTx (0)；
中断；
｝

//
//我们仍处于发送配置描述符的过程中
//因此在 EP0StateTxConfig()函数中处理此项。
//
案例 eUSBStateTxConfig：
｛
USBDEP0StateTxConfig (0)；
中断；
｝ 

第二个是 EP0的配置。

如果 EP0不起作用、我们将有100多个客户感到沮丧、因为正如您确定的那样、这对于您的应用至关重要。

您应该确保您的 TivaWare USB 库遵循概述的调用层次结构、因为如果没有、您可能会以导致问题的方式更改某些内容。 但如果确实如此、则会创建 EP0、您需要遵循我的建议并获取 USB 分析仪来实际查看通信并意识到 EP0在功能上工作。

您好、Ralph、

奇怪的是、EP0需要上述文本蓝色突出显示(简写)状态批量控制端点。 也许 EP0 最好先在 USBDCDInit()内部进行配置、并且在 USBDEP0StateTx()中似乎没有完全配置、我将调试确认 中断实际 发生。 与 EP0在有限的控制下工作时类似、但同样有问题、 当 USB0没有随机具有 AHB 优先级状态时、空闲超时挂起。 配置 USB 外设寄存器似乎更好， USBHostEndpointConfig()直接 配置它们。   寄存器改变后 EP0更加稳定、即使我  已经将 NAK 毫秒超时值与目标端点0反相。 执行图示。  

更多信息如下：1023字节批量数据包讨论(全速)模式与器件描述符文本、512字节数据包( 简而言之)相矛盾。 自 USB3.0以来、大量 Google 的抖动都是关于 USB2.0这两种速度和大容量数据包大小的问题。

数据包：

有两种类型的数据包、每个数据包能够传输高达1024字节的数据。

Data0

数据1

高速模式定义另外两个数据 PID、DATA2和 MDATA。

数据包具有以下格式、

同步 PID 数据 CRC16 EOP

低速器件的最大数据有效载荷大小为8字节。

全速器件的最大数据有效载荷大小为1023字节。

高速器件的最大数据有效载荷大小为1024字节。

μ数据必须以字节的倍数发送。

已确认(eUSBModeDevice、eUSBModeForceDevice)模式也 无法设置断开中断、并且 所有其他 (假定的)屏蔽中断都不会发生。 同样、假定 的 INTS 被下面的调用屏蔽、 并且 USBPOWER 寄存器 指示 VBUS 在电缆插入/拔出时的切换。 但是、断开 INT 永远不会触发、任何其他屏蔽 的 INT 也不会改变状态。 此问题涉及 USB 控制器模式 检测故障、VBUS/ID 引脚状态也应触发硬件断开屏蔽的中断、但无法触发。 也就是说、如果它们被屏蔽、或者 ID 引脚中断有效中断 在某种程度上限制了其他中断源？

因此、RESUME 永远不会在 挂起后发生、NAK 超时可能随机发生、 所有置位的中断事件 都应该触发 USB 库硬件中断处理程序调用、但绝不会触发。

//
//启用 USB 中断。
//
MAP_USBIntEnableControl (USB0_BASE、USB_INTCTRL_RESET |
USB_INTCTRL_DISCONNECT |
USB_INTCTRL_RESUME |
USB_INTCTRL_SUSPEND |
USB_INTCTRL_SOF)； 

void
USBIntEnableControl (uint32_t ui32Base、uint32_t ui32Flags)
｛
//
//检查参数。
//
断言(ui32Base == USB0_BASE)；
assert (((ui32Flags &(~USB_INTCTRL_ALL))= 0)；

//
//如果启用了任何常规中断，则写入通用中断
//中断设置输出到硬件。
//
if (ui32Flags & USB_INTCTRL_STATUS)
｛
HWREGB (ui32Base + USB_O_IE)|= ui32Flags；
｝ 

//
//启用 ID 引脚检测中断。
//
if (ui32Flags & USB_INTCTRL_MODE_DETECT)
｛
HWREG (USB0_BASE + USB_O_IDVIM)= USB_IDVIM_ID；
｝ 

其中是 NVIC 全局中断58的 USBIntClear ()。 startup_ccs.c -> USB0DeviceIntHandler()不是 RTOS？  似乎 中断源 IntEnable()后跟不存在的 USBIntClear ()。 即使与 最初编码 的 RTOS 信标(OS_INT_ENABLE)一样、中断也不会被触发、也许 只有在 复位期间才会触发一次、但再也不会触发。 为了使 USB0成为一 个全局信标 CMIS 触发的中断源，调用显示在 IntEnable()下面。 我们希望它能正常工作、我们不必定期调用 USBOTGMain()来获得设置/处理 USB 中断源的轮询间隔。

测试表明 INT58永远不会以任何方式被配置(SW/HW)。  然而 、VBUS 切换 为低电平 、从 Micro-B 上拔下电缆、断开中断状态 永远不会发生。 这种确认挂起、 恢复、SOF 中断状态也是 MIA。 我希望 EP1  复合接口功能的最小功能性水平上的断开中断状态。

 

//
//启用 USB 中断。
//
///OS/OS_INT_ENABLE (g_psDCDInst[0].ui32IntNum)
MAP_IntEnable (INT_USB0)； 

//启用 USB0全局 NVIC 中断源信标
//触发软件，CMIS 中断。

HWREG (NVIC_SW_TRIG)= INT_USB0 - 16； 

您好 BP101、

您能否概述您所做的测试并在我们的 LaunchPad 上尝试一下？ 如果您可以使用 TivaWare 示例重新创建这个假设的非触发中断、也许我可以深入了解并解释您看到的内容、因为我们的示例肯定会触发中断、所以这可能是调试方法的一个问题、导致您无法在上看到中断 您的硬件。

仍在等待 USB 分析仪捕获以解决恢复/挂起问题。