• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 0 subscribers
  • Views 167 views
  • Users 0 members are here
Options
Options
Similar topics

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.

[参考译文] TM4C1294KCPDT：禁用 USB0模拟 VBUS/ID 引脚

admin
Guru**** 1552380 points
Other Parts Discussed in Thread: TIDM-TM4C129USBHS
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/720384/tm4c1294kcpdt-disabled-usb0-analog-vbus-id-pins

器件型号：TM4C1294KCPDT

在有些情况下、 通过    USBGPCS 进行的外部未配置模拟 VBUS、ID 引脚寄存器控制 可能会随机地在 USBLIB 控制中恢复到 POR 状态。

Tivaware USB 库是否随机检查 USBGPCS 0x41C 的状态以确定主机连接的端点是否仍然连接？

 VBUS 似乎  未配置、ID 引脚通过 USBGPCS 强制为高电平、 如果在  某个一致 的时间范围内不刷新、则可能会任意地吊销引脚启用状态。 同样、启用 GPIO 的模拟 VBUS、ID 引脚断开客户端端点连接的频率似乎较低、但也会随机发生。  相对于 同时占用 AHB 总线的其他外设、USB0时钟控制和寄存器读取似乎并不没有缺陷。  

点是 USB0的 AHB 时序、寄存器对 USBGPCS 的读取 随机显示了当  多个其他 NVIC 中断源(持续)占用 AHB 时跳过 CPU 节拍的证据(勘误表)。 这是在 USB0端点的不稳定行为中可以得出的最合乎逻辑的扣减、因为没有 充分理由随机断开连接。 我们碰巧将高 PWM 外设连接到活动 状态、而 NVIC 和应用程序执行(CPU) 在 AHB 时序问题中极有可能出现 与 USB 库调用相关的问题、从  USBGPCS 寄存器中设置的位刷新状态。

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 BP101：

    您是指 USB#03勘误表、还是要澄清您所指的勘误表？ USB#03仅适用于器件版本1、恐怕不适用于您的器件。 此勘误表可能会影响访问 USBPC 后读取的非 USB 寄存器。 此勘误表不影响 USBPC 寄存器的读数。

    如果您怀疑寄存器被 USBLIB 意外更改、您是否可以为任何写入 USBGPCS 寄存器的操作设置一个观察点。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Charles、

    由于 在 客户端 发布异常后进入 PC (CDC)的目标接口链路保持连接、因此 USBGPCS 似乎没有变化。 批量设备客户端异常报告 在断开端点后 RX 管道中发生错误？

    USB 节拍定时器调用7个已建立的端点 、在错过的节拍周期内似乎无法扫描 USBGPCS 寄存器。  因此、计时器会认为客户端在不启动端点断开时启动了端点断开连接。 通常、如果从目标或主机上拔下 USB 电缆、则会发生远程管道的 USB 端点拆卸。 除非我们从端口上物理移除 USB 电缆、否则调试观察 USB0连接状态(UARRTprintf ())绝不会报告断开连接/连接。  当  禁用模拟 GIPO PB1、PB2时、可切换 VBUS/ID 引脚极性或通过 USBGPCS 寄存器强制拉高。 因此、在更新或配置 USBGPCS 的方式中、也会发生相同的端点异常故障。

    奇怪   的是、只有6个节拍处理器配置用于7个批量端点、在 AHB 流量较重的情况下、端点管道数据的 UDMA 传输可能无法足够快地清空环形缓冲区。 有时 、Windows 批量客户端上的管道异常会立即发生。 在 AHB 流量较重的其他情况下、多个 IOT 可变打印状态的批量数据传输 会持续几 个报告周期、然后崩溃。 修复目标 批量器件端点的唯一方法 是 重新插入 USB 电缆并 重新启动  器件客户端。  目标应自动重建 断开的管道、因为 USBGPCS 从未指示 USB 电缆已从目标上拔下。 似乎链接到 CDC 低级驱动程序     的7个端点应始终通过 tick 处理程序和循环 USB 库调用作为目标端点管道链接的一部分进行刷新。 这甚至可能是要指责的批量设备 Windows 客户端、但 管道断开似乎是从目标发起的。 

    bool
USBDeviceConfig (tDCDInstance * psDevInst、const tConfigHeader * psConfig)
｛
uint32_t ui32Loop、ui32Count、ui32NumInterfaces、ui32EpIndex、ui32EpType、
ui32MaxPkt、ui32NumEndpoints、ui32Flags、ui32BytesUsed、
ui32段；
tInterfaceDescriptor *psInterface;
tEndpointDescriptor *psEndpoint；
tUSBEndpointInfo psEPInfo[NUM_USB_EP - 1]；//NUM_USB_EP = 8

//
//此配置描述的端点总数是多少？
//
ui32NumEndpoints = USBDCDConfigDescGetNum (psConfig、
USB_DTYPE_终结 点)；
｝ 

    //
//
//此内部函数初始化处理计时器
//节拍中使用的变量。
//
//此函数只能从 USB 库中调用。 它设置
//以确保在必要时可以多次调用，而不
擦除//之前的配置(以适应 OTG 模式切换)。
//
//\返回无。
////
*****************
void
InternalUSBTickInit (void)
｛
uint32_t ui32Loop；

if (！g_bUSBTimerInitialized)
｛
for (ui32Loop = 0；ui32Loop < MAX_USB_TICK _处理程序；ui32Loop ++)
｛
G_pfnTickHandlers[ui32Loop ]=(tUSBTickHandler) 0；
G_pvTickInstance[ui32Loop ]= 0；
｝

G_bUSBTimerInitialized = true；
｝
｝

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

     另一个与 USB 机罩下的模块时序相关的发现可能与 CPU   未分频注意的高优先级外设(PWM、ADC0)中断的保养间隔相关。 

    //
//
// usblibpriv.h -用于共享内部变量和
//的私有头文件 不同模块之间的函数原型
// 库。 应用程序代码不得使用此标头。 
    //
//
//在器件和
//主机模式中从主向量调用的内部中断处理程序。
////
*****************
extern void USBDeviceIntHandlerInternal (uint32_t ui32Index、
uint32_t ui32Status)；
extern void USBHostIntHandlerInternal (uint32_t ui32Index、uint32_t ui32Status)； 

    //
//
//系统中可以注册的最大节拍处理程序数。
////
*****************
#define MAX_USB_TICK 处理程序 6

//*************
//
//此值定义在对
InternalUSBStartOfFrameTick 进行调用之前必须通过的 SOF 节拍数//。 值5确保
每5毫秒调用一次//函数、前提是启用了 SOF 中断
并且存在 SOF。
////
*****************
#define USB_SOF_TICK 除法5

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 BP101：
    此问题是否已解决？
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    嗯、这是一次尝试并理解为什么目标 MCU 会退回 USB0端点管道的尝试。 它是否已解决？ 在(快速) PWM0活动期间、即使通过直接控制 VBUS 引脚、USB 端点管道也不会保持连接。 NVIC 将优先级从 USB0 0x80更改为 PWM0 0x20的速度似乎是批量器件 FIFO 管道崩溃的原因或时间的一部分。

    因此，问题仍然存在。 但显示主机 VBUS 保持启用、消除了主机成为问题原因的疑虑。 还编写了几种恢复方法、批量客户端尝试在仍连接的端点中重新建立管道。 无法从主机设备驱动程序中的目标弹出管道中恢复，在客户端关闭、USB 电缆重新插入、客户端再次打开之前，拒绝重新连接目标管道。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Charles、

    奇怪的是、将 USB 时钟分频值设置为8=60MHz、16=30MHz、这两个值最终都会随机关闭端管道。 但是、请在 PLL=480MHz 时设置 PLL 分频系数30=16MHz USB 时钟、似乎可以阻止大容量器件客户端更频繁的末端管道错误。 (USBdenum.c) USBDCDInit（)将 USB 时钟配置为 PLL=480MHz。

    根据数据表、USB 如何甚至可以在16MHz 下运行、它必须是60MHz？

    USB 时钟控制
    当 USB 模块使用集成的 USB PHY 时、MOSC 必须是时钟源、无论是否使用 PLL、并且系统时钟必须至少为30MHz。 此外、只能使用整数除数来实现60MHz USB 时钟源。 小数除数可能会增加抖动并影响 USB 功能。 USB 时钟控制寄存器(USBCC)包含的内容
    一个 CLKDIV 位字段、可被编程为指定用于将 PLL VCO 输出减少为 USB 控制器串行化/解串化模块所需的60MHz 时钟源的分频值。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 BP101、

    并非所有外设都已"锁定"以防止超出规格、但当不以60MHz 运行 USB 时、器件被视为超出规格、TI 对任何性能不承担任何责任、因为它违反了数据表要求。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    我认为 数据表并不是专门针对  典型的 USB 单点连接、而是给出了一个总括声明、要求在外部 PHY (集线器)要求60MHz 时钟速率的情况下实现480Mbps 的传输速度。 无法实现到 端点的480Mbps 数据包传输、因此 我需要了解外部 PHY 总线速度   是文本所指的内容。 希望 NDA USB PDF 对此要求有更好的了解。

    至少在16MHz USB 时钟和25MHz MOSC 下、目标方不会随机地对主机器件的末端管道进行散列。 在 缓冲器完全状态处理的 USB 库管理中、似乎并不完全正确、因为 即使 在16MHz 下、它也会通过高速数据传输来使终端管道迅速崩溃。  下面 是数据包传输 完成 后的阈值测试、检查环形缓冲区空间是否 小于128字节。 禁用缓冲区检查 会导致通过  非中断 的数据包 传输快速对终端管道客户端进行散列。 通常 、应用 会以 1秒的间隔处理64字节数据包传输到批量器件。 因此  、这不像向  批量设备客户端传输非中断的数据包那样易失。 即使是1秒的间隔 、当 AHB 在高优先级 NVIC INT 挂起时变得真正繁忙时、似乎也会从阻止的 USB 状态更新中快速填充缓冲区。   

    //
uint32_t
TxHandler (void *pvCBData、uint32_t ui32Event、uint32_t ui32MsgValue、
void *pvMsgData)
｛
uint32_t ui32space；
//
//我们不需要对任何发送事件进行任何响应
//。 我们所做的就是更新传输计数器。
//
if (ui32Event == USB_EVENT_TX_COMPLETE)
｛
//
//传输缓冲区中有多少空间？
//
ui32Space = USBBufferSpaceAvailable (&g_sTxBuffer)；

if (ui32Space < 128)
｛
/*刷新任何溢出数据的 TX 缓冲区*/
USBBufferFlush (&g_sTxBuffer)；
｝

G_ui32TxCount += ui32MsgValue；
｝
返回(0)；
}

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 BP101、

    [引用 user="BP101"]在 缓冲区完整状态处理的 USB 库管理中，似乎有些事情并不完全正确，因为 即使 在16MHz 下，它也会通过高速数据传输来使终端管道迅速崩溃。

    您是真正使用高速模式还是仅使用全速模式？ 没有多少人使用高速模式。 如果您使用的是高速、请检查应用以下错误修复是否有帮助： e2e.ti.com/.../2518648

    [引用 USER="BP101]< 数据包传输 完成 后的阈值测试，检查环形缓冲区空间是否 小于128字节。 禁用缓冲区检查 会导致通过  非中断 的数据包 传输快速对终端管道客户端进行 trashing。

    我不确定您在这里要证明的是什么、当然、禁用缓冲区检查会使情况变得混乱。 如果不需要它、那么它就不会出现在第一个位置。

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    根据我的理解、USB0初始化期间正在设置 Bulk 器件驱动程序处于高速模式。

    缓冲区状态是由我添加的、USB 库应该处理缓冲区空间状态回调、但当通过(USB_bulk_structs.c) typedef 结构体定义的缓冲区大小直接调用 USBBufferWrite()时、它不是一个很好的操作。

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    BTW 批量设备驱动程序初始化 DCD 模式而不是 DCH、我猜 H 指定了为 HID 驱动程序支持配置的 USB。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 BP101、

    USB 高速并不是那么简单... 您需要一个外部高速 USB PHY 来将高速与器件一起使用、然后必须打开正在使用高速的软件。

    有关详细信息、请参阅 www.ti.com/.../TIDM-TM4C129USBHS。

    绝大多数应用都是在全速模式下完成的。

    关于缓冲区检查、您能详细介绍一下 TxHandler 吗？ 它用于哪一层？ 什么中断(如果有)会触发它？ 它是否基于我可以比较的任何 TivaWare 文件、以便更好地了解正在发生的情况？ 如果 TxHandler 不是 USB 堆栈的一部分、那么它与"绑定管道"有何关系？
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 BP101、

    我需要查看完整的变量或函数名称、但我想 D 表示器件、H 表示主机。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Ralph、

    没错、它实际上是主机与器件的对比。

    针对写入缓冲器通道控制的 USB 库更低级回调状态更新并不(始终)与64字节数据包(256Kbps)保持同步、无论配置的结构 R/W 缓冲器有多大。 假设16MHz USB 时钟足够快、可支持4通道串行化或256kbps*16x*4ch=16、384、000mHz。 当 USB 时钟>=30MHz 时、USB 写入缓冲区的填充速度会更快、这也许是为什么缓冲区溢出阈值会在 USB 时钟速率降低的情况下提高的原因。

    有人能不能看一下为什么 USBWriteBuffer()会泛洪(USB_bulk_structs.c)高速模式 WR 缓冲器？ 添加我的次级缓冲器控件不会阻止终端管道最终在目标的较低级别折叠。 在数据包传输过程中、AHB 流量会被拾取、客户端缓冲区状态更新的 USB 回调会被延迟。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    [引用用户="Ralph Jacobi">USB 高速并不是那么简单... 您需要一个外部高速 USB PHY 来将高速与器件一起使用、然后必须打开正在使用高速的软件。 [/报价]

    由于 ULPI 功能从未设置 (USB_dev_bulk.c) 调用 USBBulkInit()调用 USBDCDInit()，因此设备模式默认为 fs。  在下面、 如果从未配置 ULPI 功能模式、速度看起来实际上默认为 FS？

    usbdenum.c -> USBDCDInit() 

    //
//配置 ULPI 支持。
//
if (g_ui32ULPISupport！= USBLIB_FEATE_ULPI_NONE)//none=0x0000.0000
｛
USBULPIEnable (USB0_BASE)；

if (g_ui32ULPISupport 和 USBLIB_FEATE_ULPI_HS)
｛
ULPIConfigSet (USB0_BASE、ULPI_CFG_HS)；
｝
其他
｛
ULPIConfigSet (USB0_BASE、ULPI_CFG_FS)；
｝
｝
其他
｛
USBULPIDisable (USB0_BASE)；
｝

     

  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    为 ULPI 模式配置 USB 功能集、启用/禁用并为 FS 或 HS 配置 USB_ULPI 在 USB 初始化期间锁定 MCU。 似乎批量器件不使用 FS 或 HS 模式、并在 USB 库中进行另一种更低级的 DEVICE_MODE 设置。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 BP101、

    您的 MCU 是否连接了 USB 高速 ULPI 接口？ ULPI 用于与外部 PHY 连接、以使高速 USB 正常工作。 这就是我在参考设计之前发布的 TI 参考设计。 它包含硬件设计注意事项并提供软件配置。 甚至我们的 LaunchPad 也不支持硬件级的高速、仅支持全速。 这也是所有 TivaWare 将所有内容默认为 FS 的原因、用户必须竭尽全力配置 HS。。。 实际上可以使用 HS 的任何人都将设计硬件来支持它、打开一些旋钮不会有太多负担、但从 LaunchPad 等工作的任何人都只能使用 FS。

    尽管如此、我的理解是您的电路板上没有构建该附加硬件、因为它基于 LaunchPad 设计、因此您也应该使用 USB 全速模式。
  • 0
    TI__Guru**** 1552380 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Ralph、

    源代码不会使这一点变得如此清楚，并且在设置为禁用或 ULPI_NONE 时将 LPM 置于 ULPI 控件 UBSOTGFeatureSet()下，使主题变得复杂。

    它似乎以某种方式唤醒和其他 LPM 模式是用于 OTG 器件支持的 ULPI 的一部分。 似乎还需要通过 USB0的 HIB 模块电源控制实现 LMP 控制。 也许是灰色区域、或者有人在文本中使用了首字母缩略词 ULPI 来包括在 FS 模式下也可用的 LPM 参数？