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.

[参考译文] DP83867IR:跟进 PHY 的异常软复位问题

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

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1483733/dp83867ir-follow-up-for-abnormal-soft-reset-issue-of-phy

器件型号:DP83867IR

工具/软件:

您好 Evan、

我为这一个打开了一个公共线程。

(+) DP83867IR:软件复位后的异常行为-接口-内部论坛-接口-内部- TI E2E 支持论坛

因为我要休假一段时间、所以我把讨论的内容公开、让任富联络。

目前我们有两个申请:

1. 我们是否得到了反馈检查上升时序规格。 与设计团队合作?

2.如果我们将 EVM 重新设计为0.1uF / 1uF、测试结果如何?

另外、对于仁孚、请您帮助解决以下两个问题:

1.是否有0.1uF 的示波器?

2.您还能否分享有关通过 MDIO 读取 PHY 寄存器的故障症状的更多详细信息、但以太网和 LED 的功能异常?

只有链路连接失败吗?在不同通过/失败的情况下读取寄存器转储时、寄存器配置是否有任何差异?

谢谢。

我们在此处通过 E2E 进行讨论。

Matt 的答复:

1. 我们是否得到了反馈检查上升时序规格。 与设计团队合作?

2.如果我们将 EVM 重新设计为0.1uF / 1uF、测试结果如何?

1.设计团队分享反馈,这预计不会有问题,只要遵循最小低脉冲宽度(1us),就没有上升时间规格。 但是、他们正在进行调查以确认任何可能的边缘案例。

2.我能够将上升时间减慢到200us 左右,但没有发现任何问题。 我将继续探讨其他增加上升时间并与设计团队一起复制的方法。

仁孚对上述问题的反馈将有助于将此问题放在上下文中。

此致、
Dave

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

    连接了   10k Ω+ 0.1uF 的复位波形。

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

    感谢您分享示波器捕获 Renfu。

    请帮助澄清以下问题:

    [引述 userid="482354" url="~/support/interface-group/interface/f/interface-forum/1483733/dp83867ir-follow-up-for-abnormal-soft-reset-issue-of-phy

    2.您还能否分享有关通过 MDIO 读取 PHY 寄存器的故障症状的更多详细信息、但以太网和 LED 的功能异常?

    [/报价]

    谢谢您、

    Evan

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

    尊敬的 Evan:

    有两种故障症状:

    情形1: PHY LED 亮起、PHY 出现在 MDIO 总线上、但无法启动。
    情形2: PHY LED 亮起、但 PHY 在 MDIO 总线上没有响应。

    我们可以看到案例2的故障症状 U-Boot 输出如下所示:

    Could not get PHY for ethernet@8000000port@1: addr 1
    ERR.eth, am65_cpsw_nuss_port ethernet@8000000ethernet@8000000port@2: phy_connect() failed
    INFO.dma, ti-udma dma-controller@485c0000: k3_dmaring Ring probed rings:288, sci-dev-id:30
    INFO.dma, ti-udma dma-controller@485c0000: dma-ring-reset-quirk: disabled
    ethernet@8000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT !
    ERR.eth, am65_cpsw_nuss_port ethernet@8000000port@1: phy_startup failed
    ERR.eth, am65_cpsw_nuss_port ethernet@8000000port@1: am65_cpsw_start end error
     
    ERROR:   Unhandled External Abort received on 0x80000000 from EL2
    ERROR:   exception reason=1 syndrome=0x92000010
    Unhandled Exception from EL2
    x0             = 0x0000000008000f00
    x1             = 0x0000000000000001
    x2             = 0x00000000ffffffff
    x3             = 0x0000000000000002
    x4             = 0x00000000fff3199c
    x5             = 0x0000000000000002
    x6             = 0x00000000000044e0
    x7             = 0x00000000fdec5190
    x8             = 0x0000000000000000
    x9             = 0x0000000000000008
    x10            = 0x0000000000000002
    x11            = 0x0000000000000001
    x12            = 0x00000000000044e0
    x13            = 0x00000000fdeaebac
    x14            = 0x00000000fdeaf690
    x15            = 0x0000000000000020
    x16            = 0x00000000fff26360
    x17            = 0x0000000000000000
    x18            = 0x00000000fdebadb0
    x19            = 0x00000000fdeaeb94
    x20            = 0x00000000fdec51b0
    x21            = 0x0000000000000001
    x22            = 0x00000000ffffffff
    x23            = 0x0000000000000001
    x24            = 0x00000000fdec51b0
    x25            = 0x0000000000000002
    x26            = 0x0000000000000000
    x27            = 0x00000000ffffffff
    x28            = 0x000000001fffffff
    x29            = 0x00000000fdeaeaf0
    x30            = 0x00000000fff327a0
    scr_el3        = 0x000000000000073d
    sctlr_el3      = 0x0000000030cd183f
    cptr_el3       = 0x0000000000000000
    tcr_el3        = 0x0000000080803520
    daif           = 0x00000000000002c0
    mair_el3       = 0x00000000004404ff
    spsr_el3       = 0x00000000400003c9
    elr_el3        = 0x00000000fff319c0
    ttbr0_el3      = 0x00000000701ce800
    esr_el3        = 0x0000000092000010
    far_el3        = 0x0000000008000f04
    spsr_el1       = 0x0000000000000000
    elr_el1        = 0x0000000000000000
    spsr_abt       = 0x0000000000000000
    spsr_und       = 0x0000000000000000
    spsr_irq       = 0x0000000000000000
    spsr_fiq       = 0x0000000000000000
    sctlr_el1      = 0x0000000030d00801
    actlr_el1      = 0x0000000000000000
    cpacr_el1      = 0x0000000000000000
    csselr_el1     = 0x0000000000000000
    sp_el1         = 0x0000000000000000
    esr_el1        = 0x0000000000000000
    ttbr0_el1      = 0x0000000000000000
    ttbr1_el1      = 0x0000000000000000
    mair_el1       = 0x0000000000000000
    amair_el1      = 0x0000000000000000
    tcr_el1        = 0x0000000000800080
    tpidr_el1      = 0x0000000000000000
    tpidr_el0      = 0x0000000000000000
    tpidrro_el0    = 0x0000000000000000
    par_el1        = 0x0000000000000000
    mpidr_el1      = 0x0000000080000000
    afsr0_el1      = 0x0000000000000000
    afsr1_el1      = 0x0000000000000000
    contextidr_el1 = 0x0000000000000000
    vbar_el1       = 0x0000000000000000
    cntp_ctl_el0   = 0x0000000000000000
    cntp_cval_el0  = 0x0000000000000000
    cntv_ctl_el0   = 0x0000000000000000
    cntv_cval_el0  = 0x0000000000000000
    cntkctl_el1    = 0x0000000000000000
    sp_el0         = 0x00000000701cb400
    isr_el1        = 0x0000000000000000
    dacr32_el2     = 0x0000000000000000
    ifsr32_el2     = 0x0000000000000000
    cpuectlr_el1   = 0x0000000000000040
    cpumerrsr_el1  = 0x0000000001040346
    l2merrsr_el1   = 0x0000000013283c20
    cpuactlr_el1   = 0x00001000090ca000
    ?
    U-Boot SPL 0000.00-g830df3c9 (Dec 31 2024 - 14:47:56 +0800)
    resetting ...

    谢谢、

    Sean

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

    您好 Sean、

    观察到该 LED_0或 LED_1为静态开启吗?

    如果这是链路状态 LED、我会怀疑 PHY 已正确通电、并且存在可能导致此崩溃的软件依赖关系。 您是否能够引导至 Linux 并观察到相同的问题?

    我正在为 EP 团队添加标记、以帮助隔离可能的软件依赖性。

    谢谢您、

    Evan

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

    接下来、在此 uboot 失败后、您是否还尝试过寄存器访问? MAC 可能会在引导期间看到 PHY 处于复位状态、从而显示此故障。 在这种情况下、MDIO 访问在引导后仍然有效。

    谢谢您、

    Evan

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

    您好 Evan

    顺便说一下...
    TI 是否通过延长复位引脚的上升时间重现了问题?

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

    尊敬的 Renfu:

    我们已经以~300us 的上升时间进行了测试、其中 PHY 链路和寄存器访问仍然有效。

    设计团队的反馈是、复位上升时间不应影响 867功能。 请帮助确认我之前回复中的问题。

    谢谢您、
    Evan

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

    尊敬的 Evan:

    我仍然认为、上升时间是我们需要重点关注的关键点。

    根据 UC-2222A 设计、800us 的上升时间仍对某些 PHY 芯片有效。

    我尝试将上升时间延长至10ms 以上、这时就会出现故障现象。

    您可以重试吗?

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

    uC-2222A 软件复位不会关闭 PHY 的操作。

    它仍保持上电状态、只需在 PHY 的硬件复位引脚(PIN.59 RESET_N)上触发低电平脉冲。

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

    有时、我们无法通过 MDIO 从 PHY 获取信息。

    因此、我认为使用 MDIO 作为解决问题的路径可能是不可行的。

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

    尊敬的 Evan:

    只有有问题的 PHY 不会出现在 MDIO 总线上;其他 PHY 功能正常。 我认为在这种情况下 MAC 是可以的。

    Linux 中会显示以下消息:

    am65-cpsw-nuss 8000000.ethernet: phy /bus@f4000/ethernet@8000000/mdio@f00/ethernet-phy@1 not found on slave 2

    谢谢、

    Sean

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

    尊敬的 Renfu、Sean、

    感谢您分享调查结果。 我将继续重复生成更长的上升时间、以找到任何限值。

    BR、

    Evan

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

    您好 Evan

    您是否通过增加复位信号的上升时间复制了这个 PHY 问题?

    另外、请帮助提供最新的状态更新。

    谢谢。

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

    尊敬的 Renfu:

    最新测试是300us 上升时间、无问题。
    我将最迟在星期四分享与您的系统相同上升时间的结果。

    谢谢您、
    Evan

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

    尊敬的 Evan:

    我们产品中的大多数 PHY 都运行速度很慢、并且运行正常、故障情况非常少见。 我认为失败的情况很难重现。

    为了解决这个问题、我们进行的唯一调整是加快上升时间、我认为这是关键因素。 这可能是关键点之一。

    我们仍在生产中的产品、希望了解 TI 建议的上升时间 然后再确定根本原因。

    谢谢、

    Sean

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

    您好 Sean、

    建议使用最短 RESET 上升时间。

    此建议不是出于芯片级问题、而是为了应对可能出现的系统级问题、如果 PHY 复位未在指定时间内完成、则 SoC 状态机可能会受到影响。 请与 SoC 团队确认任何对复位时序的依赖关系、以实现正确的初始化。

    谢谢您、
    Evan

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

    您好 Sean、Renfu、

    我在 DP83867EVM 上以以下上升时间~40ms 进行了测试、超过100次下电上电、并且在寄存器访问或链接方面未发现任何问题:

    因此、我认为您的问题取决于 MAC 侧。 当 SoC 初始化 MDIO 总线时、是否存在与复位时序相关的任何问题?

    在失败的情况下、您是否可以尝试使用 phytool 或 MDIO-TOOL 手动读取寄存器? 我想知道寄存器访问失败是否特定于 MAC 函数、或者任何寄存器访问尝试都会失败。

    谢谢您、
    Evan

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

    您好 Evan

    只是为了确认,状态只由 HW reset_N 信号触发,没有断电操作,对吧?

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

    正确。

    EVM 原理图位于此处:
    https://www.ti.com/lit/ug/snlu190/snlu190.pdf

    测试条件:

    • 在"RESET_N"上向 VDDIO 添加20k
    • 在"RESET_N"上将2.2uF 添加到 GND
    • 按下并释放"S1"使 RESET_N 脉冲接地。
    • 读取寄存器和测试链接

    谢谢您、
    Evan

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

    一次后续测试、您能否在尝试访问寄存器时探测 MDIO?

    这样我们可以确定故障是由 MAC 侧还是 PHY 侧依赖导致:

    -在寄存器访问期间不存在 MDIO 意味着 MAC 由于 MDIO 总线初始化失败而不驱动这条线路(PHY 正常)

    - MDIO 在寄存器访问期间活动,但 PHY 没有以正确的值响应(PHY 无法正常启动)

    谢谢您、
    Evan   

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

    尊敬的 Evan:

    我们发现、该问题可能是由于 PHY 错误地锁存其地址而导致的。

    由于 PHY0 (PHY 地址0) 正常工作、因此 MDIO 工作正常。 以下是 PHY1 (PHY 地址1)未出现在 MDIO 总线上的故障情况。

    • PHY0工作正常

    • PHY1锁存器地址时序问题(PHY 0和 PHY 1都将其地址视为0)  

    • PHY1不会出现在 MDIO 总线上。

    附加的 MDIO.CVS 文件包含 MDIO 总线上的消息

    e2e.ti.com/.../MDIO.csv

    随着我们加快 RESET 上升时间、两个 PHY 都正常运行。 以下是供您参考的锁存时序:

    • PHY1锁存器地址时序

    • PHY1出现在 MDIO 总线上。

    在加快复位上升时间可以解决我们的问题的同时、我们有点担心 PHY 地址锁存器时序是否符合预期的规范。

    谢谢、

    Sean

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

    您好 Sean、

    PHY 地址搭接引脚为 MAC RX 线。 我怀疑、为了延长复位时间、MAC 侧的引脚状态会发生变化并影响锁存时的采样电压。 请确认 MAC 的 RX[D0、D2、D4]引脚状态是否在该复位时序裕度内变化。 在慢速/快速复位情况下捕获这些线路的波形也有助于确认这一点。

    谢谢您、
    Evan

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

    您好 Evan

    我们在 EVM 上看不到问题。 可能是因为它只有一个 PHY 并且地址设置为默认值(地址0)?

    我尝试 在 MOXA/uC-2222A 单元上捕获波形。 您能帮助我验证时序是否符合规格吗?

    我们在设计中使用地址0和地址1、因此我只在 wavefrom 上捕获 RX_D0。

     RESET_N 上的 R = 10k Ω、C = 1uF

    R = 10k Ω、无电容器。 约为7000

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

    尊敬的 Renfu:

    相对于我之前的答复、我怀疑867EVM 不会遇到此问题、因为没有 MAC 连接到 RX_D[...] 影响锁存输入引脚电压的线。

    [引述 userid="645057" url="~/support/interface-group/interface/f/interface-forum/1483733/dp83867ir-follow-up-for-abnormal-soft-reset-issue-of-phy/5713395 #5713395"]

    我们在设计中使用地址0和地址1、因此我只在 wavefrom 上捕获 RX_D0。

    [/报价]

    其他地址配置(RX_D2/RX_D4)可能会在启动时受到 MAC 的影响、但 PD 在这些引脚上没有 PU/MAC 的可能性较小。 您能否分享完整的原理图以供我进行审核(可以发送电子邮件至 e-mayhew@ti.com 以供私人分享)。

    根据共享的波形、两个 PHY 看起来搭接至地址0:

    对于用于地址1的 PHY、是否可以调整 MAC 侧以保持 RX_D0 = 0.165 x VDDIO (模式2)、直到复位为高电平+ 120ns?

    谢谢您、
    Evan

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

    尊敬的 Evan:

    我已通过电子邮件向您发送了 PHY 原理图以供您参考。

    下图显示移除了0.1uF 电容器以用于测量。

    根据功能和协议检查、可以正常检测地址1。

    1. 释放复位信号后、您认为是否仍存在锁存时序问题?

    2.在锁存后、RX_D0信号由 PHY 控制、正确吗?

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

    尊敬的 Renfu:

    抱歉、我给图表贴上了误导性的标签。

    当 RESET_N (V)> VIL (0.7)时、会发生配置(strap)锁存。 这显示了 PHY 地址0x1的示波器 HOT 和更快的复位范围中 RX[D0]="1"的采样点。

    对于较慢的复位情况、请共享此区域的放大捕获图:

    我想确认在 RESET_N (0.7V)+ 120ns 之前、RX_D0是否被驱动为低电平。

    [引述 userid="645057" url="~/support/interface-group/interface/f/interface-forum/1483733/dp83867ir-follow-up-for-abnormal-soft-reset-issue-of-phy/5717062 #5717062"]

    1. 释放复位信号后、您认为是否仍存在锁存时序问题?

    2.在锁存后、RX_D0信号由 PHY 控制、正确吗?

    [/报价]

    1)在较慢的上升时间情况下、这是可能的。 我需要使用更短的时间标度来查看故障案例、以了解准确的采样点。

    2)正确的是、RX_D0将在自举锁存后由 PHY 驱动。 不过、在这一点之前、线路上的其他器件可能会影响采样电压。

    通过查看原理图、R350和 R145上填充了哪些电阻器值、地址= 0x1?

    谢谢您、
    Evan

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

    您好 Evan

    当 R = 10k Ω 且 C = 2.2uF 时
    对于较慢的 RESET 上升时间、在 RESET_N (0.7V)+ 120ns 时序时不会发生锁存操作。
    当复位电压约为1V 时、在锁存过程中、RX_D0中会出现振荡。



    当  R = 10k Ω 且 C = 100pF 时
    RX_D0可在 RESET_N (0.7V)+ 140ns 时序下锁存、地址检测和 PHY 链路功能正常。


    通过查看原理图、R350和 R145上填充了哪些电阻器值、地址= 0x1?
    => R350和 R145 不是填充、将地址设置为00000 (PHY 端口1)
    => R138上拉10k Ω、D148下拉2.49k Ω、将地址设置为00001 (PHY 端口2)

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

    尊敬的 Renfu:

    => R350和 R145 不是 stuff、将地址设置为00000 (PHY 端口1)
    => R138拉高10k 欧姆、D148拉低2.49k 欧姆、将地址设置为00001 (PHY 端口2)

    这对于预期的搭接是正确的、感谢您确认。

    上电期间 MAC 是否连接到 RXD0线路? 如果可能、请从 PHY 到 MAC 移除 RXD0连接、以确认 MAC 是否在复位期间引起这些振荡。 这些振荡可能会导致意外的 strap 配置值被锁存。

    谢谢您、
    Evan

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

    我已经切断了 SOC (MAC)和 PHY 之间的 RX_D0路径。 发现 PHY 在复位期间引起了这些振荡。

    通道2是 SOC (MAC) RX_D0、可保留原始 R138上拉10kΩ 电阻器和 D148下拉2.49kΩ 电阻器。
    通道3是 PHY RX_D0。 由于原始路径被切断、我添加了一个连接到3.3V 的上拉10kΩ 电阻器。

     

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

    尊敬的 Renfu:

    感谢您在此处分享测试结果。
    我不清楚导致此振荡的 PHY 端行为。 您是否看到 RX_CLK 或其他 RX_D[X]线路在同一采样点显示活动?

    我正在进一步与设计团队核实以确认原因。  

    谢谢您、
    Evan  

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

    尊敬的 Renfu:

    内部引脚结构是 CMOS 输入缓冲器、具体取决于复位电压、这会由于上升时间较慢而导致振荡-在未定义的逻辑区域中、持续时间较长。

    此应用手册中的图4展示了此行为的一般示例:
    https://www.ti.com/lit/an/scla015b/scla015b.pdf

    寄存器配置无法避免这种行为-这些是剩余的权变措施:

    • 调整外部无源器件以缩短复位时间
    • 如果 SoC 在 RX_D0引脚上有内部上拉电阻、则让 SoC 在复位期间暂时将此引脚驱动为模式2电压

    谢谢您、
    Evan

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

    尊敬的 Evan:

    关于更短的重置时间...

    TI 是否会定义复位的压摆率?

    建议我们使用哪些电容器值?

    谢谢、
    仁福

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

    尊敬的 Renfu:

    我们已在复位时使用0.01uF // 2.2千欧姆电阻器进行了测试、而没有出现问题。

    遗憾的是、这是我们过去没有观察到的边沿情况、因为设计的复位上升时间通常小于50微秒范围。

    如果需要、我可以进行进一步测试、以便找到确切的上升时间可接受限值-在修改设计之前、请告诉我是否需要此数据。

    谢谢您、
    Evan

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

    尊敬的 Evan:

    由于上升时间相同、不同的 PHY 芯片上可能存在不同的行为。

    我们需要 TI 提供建议的上升时间以避免此问题。

    谢谢、
    仁福

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

    尊敬的 Renfu:

    我确认建议的上升时间、会尽快分享。

    谢谢您、
    Evan

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

    您好 Evan

    您是否对上升时间规格有任何更新?

    谢谢。

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

    目前尚未开始对设计进行讨论。

    对延迟深表歉意。

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

    您好 Evan
    是否有上升时间规格的估计时间线?

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

    希望在1-2周内分享该规范。

    设计团队要求提供一些澄清信息:

    • RXD0上看到切换的周期是多少?
    • 切换的间隔是否为500ns 至700ns?

    谢谢您、
    Evan

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

    尊敬的 Renfu:

    接着是设计提供的更多反馈、规格限制不是复位信号的上升时间、而是复位线路上的噪声。

    如果复位线路上存在噪声、较慢的复位速度将为 PHY 在超过 VIL/VIH 阈值时进入和退出复位提供更多机会。

    为了确认这一点、测量 RX_D0的切换周期为500 - 700ns 将确认配置(strap)锁存会由于线路上的噪声而重复触发复位而多次发生。

    谢谢您、
    Evan

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

    您好 Evan

    您可以找到 RXD0上的12.5 MHz 切换信号相关信息

    根据切断 SoC (MAC)和 PHY 之间的 RXD0路径的结果、切换波形仍然存在。
    这是否表明噪声源自 PHY?

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

    尊敬的 Renfu:

    噪声可以从任何周围源(EMI、布局中附近的高频信号...)进行耦合

    布局是否包含 RX_D0附近的任何高频信号? 会有一些噪声从内部 PHY 信号耦合、但这通常不足以在没有额外源的情况下导致任何问题。

    谢谢您、
    Evan

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

    您好 Evan

    我进行了几个实验、但 RX_D0上仍然存在切换信号。

    -移除二极管(最初将 CPU 连接到 Phy ),同时仅保留10kΩ 电阻器和1µF 电容器在 Phy 复位路径上。

    -通过短暂地将 RESET 短接至 GND 手动生成一个低电平脉冲。

    -将 PHY 的电源更改为外部电源。

    RX_D0布线在 RX_D1和 RX_CLK 之间路由。
    我尝试将 RX_CLK 信号短接至 GND、但切换信号仍然存在。

    RESET 引脚附近没有高频信号。

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

    尊敬的 Renfu:

    感谢您分享测试数据。

    回到最初的问题、我注意到通过/失败情况下 MDIO 波形有一些差异:

    PHY1无响应:

    PHY1响应:

    在这两种情况之间、占空比和频率似乎会发生变化。 据我所知、我们重点讨论了由于这种 RX_D0切换可能导致的 Strap 配置问题、但我也想排除 SMI 上的任何时序违例:

    对于通过/失败的情况、您能否帮助确认是否满足这些时序要求?

    谢谢您、
    Evan

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

    尊敬的 Evan:
    我检查了故障单元上的 MDIO 信号、
    无论复位信号的上升速度是快还是慢、时序看起来都相同。

    Ch2:MDC
    CH3:MDIO

    输出

    发生正转换

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

    尊敬的 Renfu:

    感谢您分享这些数据、我同意这符合 SMI 规范。

    由于线路上的噪声可忽略不计、足以触发切换行为、因此我将通过设计确认复位上升时间规格、以避免这种行为。

    同时、请确认以下权变措施是否适用于您的系统:

    对于上升时间失败的情况、请扫描每个地址(0x0 - 0x1F)处的 PHY 寄存器读取/写入。 找到 PHY 意外配置的响应地址、并修改 SW、改用此地址作为总线。

    谢谢您、
    Evan

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

    您好 Evan

    此权变措施可能不可行、因为 UC-2222A 有两个 PHY、这可能会导致地址冲突。

    请帮助提供上升时间规格、以确保避免这种损耗问题。 谢谢你。

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

    我明白。 等待设计确认规格。