[参考译文] TUSB4041I：当移除器件并通过下行链路端口连接回时、集线器会与上行链路主机断开连接。

您好！

我以前没有听说过 TUSB4020/4041有这样的问题。  让我尝试在我们的实验室中重现该问题、并在3-4天内与您联系。

此致、

尼古拉斯

您好！

我能够 使用 TUSB4020BI 和一个连接锻炼器创建一个工作台设置。  我在50%占空比下执行了300个80ms 连接/分离周期。  在初始测试过程中未看到问题。

您能否提供您的原理图、以便我查看集线器的配置？  Pekka 应该能够打开一个机密的 E2E 问题来共享您的原理图。  他还可以安排会议、以便我们可以查看中心的设置并分享任何其他相关信息、从而帮助重现问题。  我已将他添加到该 E2E 票证中、以获得可见性。

谢谢。

尼古拉斯

除了我们自己的硬件、我们还能够重现连接到 Linux Fedora 笔记本电脑的 TUSB4041PAP 评估模块的问题。

那么、2端口 TUSB4020BI 的工作方式是否与4端口 TUSB4041B 不同？

我们应用中的 TUSB4041I 集线器配置如下：

SMB 正在使用中。
上电并释放 GRSTz (18)后、通过写入寄存器 F8h 中的 cfgActive 位启动集线器。
不更改寄存器中的其他配置。
SDA/SMBDAT (5)、1k 上拉至3.3V
SCL/SMBCLK (6)、上拉1k 至3.3V
SMBUSz (7)、下拉4k7

启用完整电源管理并且策略处于高电平有效状态。
FULLPWRMGMTz/SMBA1 (8)、悬空/NC
PWRCTL_POL (9)、悬空/NC
成组/SMBA2/HS_UP

禁用自动充电模式。
AUTOENz/HS_SUSPEND (13)、悬空/NC

忘记描述针脚10连接...

我们应用中的 TUSB4041I 集线器配置如下：

SMB 正在使用中。
上电并释放 GRSTz (18)后、通过写入寄存器 F8h 中的 cfgActive 位启动集线器。
不更改寄存器中的其他配置。
SDA/SMBDAT (5)、1k 上拉至3.3V
SCL/SMBCLK (6)、上拉1k 至3.3V
SMBUSz (7)、下拉4k7

启用完整电源管理并且策略处于高电平有效状态。
FULLPWRMGMTz/SMBA1 (8)、悬空/NC
PWRCTL_POL (9)、悬空/NC
成组/SMBA2/HS_UP (10)、悬空/NC

禁用自动充电模式。
AUTOENz/HS_SUSPEND (13)、悬空/NC

尊敬的 Antti：

我可能需要订购 TUSB4041PAPEVM 进行测试。  与此同时、我正在对这两个集线器进行原理图审阅、并使用匹配的设置测试 TUSB4020BI。

此致、

尼古拉斯

尊敬的 Antti：

在 Windows 操作系统中您是否看到同样的问题？  如何控制下游器件的连接/分离周期？  

此致、

尼古拉斯

可以禁用 SMBus 模式并尝试相同的测试吗？  我想知道是否存在导致 cfgActive 位未设置的时序问题。   

此致、

尼古拉斯

我认为这不是由于 SMB 已激活、因为我们可以通过单独运行且 SMB 已禁用的 TUSB4041I 评估板重现此问题。

我们尝试通过使用不同的主机器件进行测试来进一步隔离问题。

在四种不同的系统和主机中，同样的集线器消失和重新枚举问题会出现：
1.运行 Linux 和 TUSB4041PAPEVM 的 Intel Core i7笔记本电脑
2.运行 Windows 10 TUSB4041PAPEVM 的 Intel Core i7笔记本电脑
3. 运行定制 Linux 的 MX8MP 和 TUSB4041PAPEVM 直接连接到 I。 MX8MP USB 主机控制器
4.一. MXRT106x 运行的 RTOS 和 TUSB4041I 通过 TUSB4020BI 连接至 I。 MXRT106x USB 主机控制器

看起来该错误仅在释放 USB 集线器复位或通电后发生一次。
示例序列1：
1.将 TUSB4041PAPEVM 连接到主机并上电(将 SW3从"关闭"转到"总线电源")
2.观察枚举至主机的 TUSB4041I
3.将 USB FS 或 LS 设备连接到集线器下行端口
4.开始断开并重新连接下游端口上的器件
5.观察 TUSB4041I 消失后重新枚举
6.继续断开并重新连接下游端口上的器件
-> TUSB4041I 在第一次重新枚举(步骤5)后仍保持枚举状态。

示例序列2：
1.将 TUSB4041PAPEVM 连接到主机并上电(将 SW3从"关闭"转到"总线电源")
2.观察枚举至主机的 TUSB4041I
3.将 USB FS 或 LS 设备连接到集线器下行端口
4.开始断开并重新连接下游端口上的器件
5.观察 TUSB4041I 消失后重新枚举
6.继续断开并重新连接下游端口上的器件
-> TUSB4041I 在第一次重新枚举(步骤5)后仍保持枚举状态。
7.通过将引脚18 GRST_N 拉低一段时间来复位 TUSB4041I
8.观察 TUSB4041I 消失并重新枚举
9.继续断开并重新连接下游端口上的器件
10.观察 TUSB4041I 消失并重新枚举
11.继续断开并重新连接下游端口上的器件
-> TUSB4041I 在第一次重新枚举(步骤11)后仍保持枚举状态。

因此、一旦该问题发生、集线器将正常工作、直到下一次复位或下电上电。

我们也在 Windows 笔记本电脑上重现了 TUSB4020BPHPEVM 的问题。
TUSB4020BI 未在其他系统中进行测试。

是的、在 Windows 机器上也出现了问题。

在自动化测试中、我们将器件与 TS3USB221搭配使用、以断开 DP/DM 对。  TS3USB221引脚3/4为 NC、差分对通过引脚7/8和2/1进行布线。 器件 VBUS 与 P 沟道 FET (SI3483DV)同时断开。
因此、这模拟了在 VBUS 和 DP/DM 均断开时器件电缆的完全断开。

您也可以通过连接和断开连接(例如 USB 鼠标)手动重现问题。

我懂了。  感谢您采用详细的测试流程。  我们于星期一放置了 TUSB4041 EVM、一到货、我就会重现问题并找到根本原因。

谢谢。

尼古拉斯

尊敬的 Antti：

EVM 已到达、我将尽快获得结果。

此致、

尼古拉斯

尊敬的 Antti：

我用 MCCI USB 3.0连接操作器进行了同样的测试,并尝试手动连接和断开鼠标。  我能够看到如下所示的集线器"断开"的驱动程序实例,但这似乎与软件有关,并不影响集线器的功能。

在 EVM 测试程序中、SW2和 SW1设置都是默认设置？   

您能否告诉我您用于测试的 Windows 软件以及看到集线器断开连接的情况？

此致、

尼古拉斯

您好！

在 Windows 机器上、我们手动进行了测试、并使用 USB Device Tree Viewer V3.8.1观察了器件连接状态。
看起来您使用过相同的软件。

手动 插入和拔下鼠标能够导致 TUS4041I 断开。 同时、您会丢失连接到 TUSB4041I 的所有 USB 设备。 在我们的例子中、也连接了一个 USB 键盘。
这种情况只发生一次- TUSB4041I 立即断开并重新枚举、并且连接的 USB 器件也会重新枚举。

TUSB4041I 评估板开关设置为：
SW1：1=OFF、2=ON、3至7=OFF
SW2：1=ON、2至7=OFF

您必须对 TUSB4041I 进行下电上电、将 RESET 下拉为低电平、使 TUSB4041I 处于再次断开连接的状态。

在运行 Linux 或 RTOS 机器的主机上、我们可以直接从 USB 主机驱动程序观察到 TUSB4041I 消失并重新枚举。

那么、什么原因会导致 TUSB4041I 像这样断开？
看起来像是某种内部软复位、因为 SMB 寄存器值未复位为默认值、并且 TUSB4041I 在断开连接后重新枚举。

感谢 Antti、

我不知道集线器为什么会断开。  不应该这样、我需要进行亲身实践调试。  我没有可用于测试的 Linux 系统。  是否对 USB 主机/器件有任何依赖？  换言之、这是否在任何系统上都可以实现？  您是否可以发布 USB 树视图结果以便我可以查看故障条件？

今天我将继续尝试在使用 SW1/SW2设置的情况下重现此故障。  在每次测试之间、我一直在进行下电上电。  我将在 EOD 之前向您提供最新信息。

此致、

尼古拉斯

尊敬的 Antti：

我看到了问题！  我将使用 USB 协议分析器来查看可能发生的情况。

此致、

尼古拉斯

我注意到 USB 树视图中有趣的一点是、在发生故障后、端口上的文本从"Generic USB 2.1 Hub"更改为"Generic USB 2.0 Hub"。  你的情况是一样的吗?

此致、

尼古拉斯

我们已经在4个不同的系统中重现了问题。

这将表明它不依赖于 USB 主机控制器。

在四种不同的系统和主机中，同样的集线器消失和重新枚举问题会出现：
1.运行 Linux 和 TUSB4041PAPEVM 的 Intel Core i7笔记本电脑
2.运行 Windows 10和 TUSB4041PAPEVM 的 Intel Core i7笔记本电脑
3. 运行定制 Linux 的 MX8MP 和 TUSB4041PAPEVM 直接连接到 I。 MX8MP USB 主机控制器
4.一. MXRT106x 运行的 RTOS 和 TUSB4041I 通过 TUSB4020BI 连接至 I。 MXRT106x USB 主机控制器

尊敬的 Antti：

我在实验室中有一台 PC、上面有两个不同的 USB 控制器。  一个通过测试、另一个失败。

ASMedia USB3.1可扩展主机控制器：  ASMedia USB 根集线器 (失败)
Intel(R) USB 3.0可扩展主机控制器-1.0 (Microsoft)：  USB 根集线器(USB 3.0) (通过)

以执行该测试。  我运行连接到 TUSB4041PAPEVM 的低速鼠标的10个250ms 周期、250ms 周期分离。   

对于这两种情况、我都有 USB 协议跟踪、因此对通过和失败情况进行了并排比较。  我们现在正在分析数据以了解正在发生什么。

此致、

尼古拉斯

尊敬的 Antti：

以防发生故障。  我们可以看到、 在连接/断开 LS 鼠标时、此全速 J 出现在上游。  

我也使用示波器对此进行了测量。  我们正在确定此 J 的来源、以及在故障情况下而不是通过情况下导致 J 出现的原因。

此致、

尼古拉斯

尊敬的 Antii：

关于协议曲线和示波器测量的另一个有趣点。

在全速 J 之前没有 SOF 数据包。 当集线器在3ms 后没有看到来自主机的任何流量时、它应该进入挂起状态。  这并不能解释为何仅 TUSB4041发生此问题、但可能有助于说明主机在此问题中发挥的作用。

您是否能够确认您的 USB 主机控制器是否为 ASMedia？

此致、

尼古拉斯

在 Windows 10计算机上、 我们可以重现 TUSB4041I 的问题、有 Intel 控制器：
Intel(R) USB 3.1可扩展主机控制器-1.10 (Microsoft)
PNP 设备 ID：PCI\VEN_8086&DEV_A36D&Subsys_09061028&REV_10\3&11583659&0&A0

在我们重现此问题的嵌入式 Linux 和 RTOS 系统中、使用 NXP I 的集成主机控制器。 MX8MP 和 I. MXRT106x 处理器。 我相信这些使用的是 Synopsys 提供的 USB 2.0 EHCI IP。

对我来说、重现此问题的最简单方法是将鼠标连接到集线器、在400毫秒后断开连接、然后在1秒钟或更长时间后再次将其连接400毫秒。 该问题通常会在5-20个周期内重现。

我有一个  Intel(R) USB 3.0可扩展主机控制器  运行 Fedora 37 Linux 的 Dell Precision M3800笔记本电脑上。

尊敬的 Claus：

我现在可以可靠地重现此问题。  没问题。  

目前、我看到当故障发生时、SOF 包停止向集线器传输、而集线器进入挂起状态。  我还没有找到行为的原因,但我会让你知道,只要我已经缩小原因.  感谢大家取得的成绩。  我很快就会有另一个更新。

此致、

尼古拉斯

尊敬的 Claus 和 Antti：

进一步测试后、我能够在主机和 TUSB4020B 上重现此问题。

我研究了下行端口、没有发现任何异常、但连接设备后开始枚举的时间为~190ms。  这接近连接/分离循环的循环时间。  如果允许集线器有时间枚举设备、则没有问题。

无法更改 TUSB4041I 广播 bcdUSB=0x0210、因此这不是分辨率的路径。  我还尝试将 USB 2.0高速集线器的集线器下游插入、但这不会改变 bcdUSB=0x0210、因此不能解决问题。

看起来我们仅限于更改寄存器或引脚设置以找到权变措施。  今天我将这样做、看看我们是否可以修改复位时序或配置来解决问题。

此致、

尼古拉斯

尊敬的 Claus 和 Antti：

我昨天曾尝试更改许多不同的设置和寄存器、以便解决集线器的快速连接/断开问题、但我找不到可以解决该问题的设置和寄存器。

通过快速连接/分离测试的确切条件是什么？  连接/断开的周期数以及发生速度有多快？

此致、

尼古拉斯

嗨、Nicholaus：

"通过"测试意味着什么？

我之前提到过：
"对我来说、重现此问题的最简单方法是将鼠标连接到集线器、在400毫秒后断开连接、然后在1秒钟或更长时间后再次将其连接400毫秒。 问题通常会在5-20个周期内重现。"

我还没有尝试确定器件不会重新枚举到2.00模式时的最短连接/断开时间。 在我们的 用例中、查找最短时间用处不大、但我明天可以进行一些测试。   

我们已经尝试过多种方法来重置集线器、上游集线器和设备。 似乎没有软件交互对这个问题产生任何影响。 实际上、要使器件通告  其自身为2.00集线器、唯一的方法似乎是断开/连接下游端口上的器件、并使其在 n 次尝试后重新枚举。 (通常在5-20次尝试之间)。

此致、

克劳斯

尊敬的 Claus：

据我所知、我们考虑这种连接/分离场景的原因是、一些专有测试需要在生产前通过。  除非您尝试使其发生、否则在现实场景中很难重现。  最终结果是集线器重新枚举并且 LS/LS/ FS 器件按预期工作。  

因此、我不是说我们需要找到最小/最大时间。  我想知道是否可以更改问题发生的时间、以便我们可以通过此测试。   如果没有定义测试、  对最终用户来说、这是什么问题？

此致、

尼古拉斯

嗨、Nicholaus：

我们面临的问题是、我们无法控制客户/用户的行为、如果客户导致问题发生、则连接到集线器的所有其他设备将重新枚举、这在我们的用例中是不好的。

通过手动连接和断开器件几秒钟、我们可以轻松重现此情况。 如果我们能做到、那么很明显客户会做到这一点。

此致、

克劳斯  

尊敬的 Claus：

我明白了。  按照 USB 2.0规范、枚举在连接后~200ms 开始、枚举在大约200ms 内完成。 Windows 集线器驱动程序还必须观察到至少100ms 的周期、在该周期中没有端口更改、如果端口在200ms 后没有稳定、集线器驱动程序将禁用端口并取消枚举。

以400ms 的间隔快速删除和插入器件会导致枚举出现问题、因为器件没有足够的时间稳定和正确枚举。 需要增加计时间隔以允许器件进行枚举。  

此致、

尼古拉斯

大家好、Nicholaus、 这个团队做的测试是 USB 子系统的可靠性测试。  在此测试期间枚举失败是可以接受的。  测试失败不是由于枚举失败所致、而是由于集线器重新枚举、导致集线器上连接的所有其他设备必须重新枚举。  假设400ms 很短、但并不超出人机交互的可能性范围。  它还明确处于连接"抖动"范围内、或者当物理线缆在所连接的 USB 电缆中出现磨损或间歇性故障时可能会遇到的情况。  同样、故障不是需要枚举的故障。  我们的系统来处理它。  此故障是集线器对故障做出反应的方式之一、通过重新枚举集线器本身来枚举、导致所有连接集线器的外设暂时断开。  团队与之合作的其他合规集线器的行为不是这样的。  如果我们更改测试时间、我们可能会达到集线器不以这种方式响应的程度。  但是、这会妨碍可靠性测试的目的。

此致、

戴夫

Dave、您好！

是的、我明白了。  但是、此问题似乎是集线器运行的一部分。   集线器不包含固件、因此无法轻松更改行为。  这意味着我们无法满足所需的分辨率时间。   

我们将在内部上报此问题、以便了解后续步骤。

此致、

尼古拉斯

嗨、Nicholaus：

我接受了你朋友的请求。 请分享该信息。

谢谢。

-克劳斯-

停止更新。  

请告诉我、设置 OTP 位是否会强制集线器连接到 USB 2.0。

此致、

尼古拉斯