[参考译文] AM6442：DP83869HM 中 BMCR 寄存器的位 11 不会变为‘1'“。

您好：

我们需要更多有关这个问题的详细信息。

1.  请注明 Ind-comms-SDK 版本和 EtherCAT 子设备示例。

2.您能否提供有关初始化序列和 PHY 驱动程序的更多信息？ 您是否在使用自己的定制 PHY 驱动程序？

3.您能提供 PHY 寄存器转储吗？

4.您是使用 AM64x TI 的 EVM 还是基于 AM64x 的定制硬件进行测试？

向  BMCR 寄存器的位 11 写入 1 是否总是会失败、或者有时会失败？

向 BMCR 寄存器的位 11 写入 1 后、是否立即执行软件复位？

DP83869HM 的 INT_N/PWDN_N 引脚使用上拉电阻器固定为高电平。

由于 INT_N/PWDN_N 引脚为低电平有效、这应该可以。

此致、

开机后、如果我们不执行重新启动或重置、而只是重新运行 EtherCAT 从站程序、就不会出现问题。
在这些情况下、AM6442 的复位似乎是该问题的触发因素。

请在 Linux 运行时检查 PHY Strap 配置、这可能与 POR 场景不同、对于确保正确完成 PHY 硬件 strap 配置以初始化 PHY 而言、这一点非常重要。

尊敬的 Harsha：

感谢您的帮助、

[quote userid=“611477" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1588218/am6442-bit-11-of-the-bmcr-register-in-the-dp83869hm-does-not-become-1/6118599   请提及 Ind-comms-SDK 版本和 EtherCAT 子器件示例。

它基于“ind_comms_sdk_am64x_09_02_00_08"中“中的“ethercat_slave_simple_demo_am64x-evm_r5fss0-0_freertos_ti-arm-clang"。“。
我们已定制定制电路板的引脚配置。
此外、我们还添加了一个资源表、以便可以从 Linux 加载该表、并实现了正常关机以启用重新加载的代码。

[quote userid=“611477" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1588218/am6442-bit-11-of-the-bmcr-register-in-the-dp83869hm-does-not-become-1/6118599 您能否提供有关初始化序列和 PHY 驱动程序的更多信息？ 您是否在使用自己的自定义 PHY 驱动程序？

我们使用示例程序中包含的“CUST_PHY_dp83869.c"。“。
未从示例程序修改初始化序列。
在调用 EC_API_SLV_run () 函数之前、执行没有错误。
我们通过添加打印语句确认了“CUST_PHY_dp83869.c"中“中定义的几个函数正在被调用。
向 BMCR 寄存器的位 11 写入“1"的“的部分位于 CUST_PHY_DP83869_setPowerMode 功能中。

[quote userid=“611477" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1588218/am6442-bit-11-of-the-bmcr-register-in-the-dp83869hm-does-not-become-1/6118599 您能否提供 PHY 寄存器转储？

这是将“1"写入“写入 BMCR 寄存器的位 11 后转储 DP83869 寄存器的结果。

e2e.ti.com/.../5707.Error.txte2e.ti.com/.../5707.Normal.txt

[引述 userid=“611477" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1588218/am6442-bit-11-of-the-bmcr-register-in-the-dp83869hm-does-not-become-1/6118599

4.您是使用 AM64x TI 的 EVM 还是基于 AM64x 的定制硬件进行测试？

向  BMCR 寄存器的位 11 写入 1 是否总是会失败、或者有时会失败？

向 BMCR 寄存器的位 11 写入 1 后、是否立即执行软件复位？

[/报价]

这不是 AM64x EVM。

向 BMCR 寄存器的位 11 写入 1 只执行一次操作。

此外,我尝试重复写一个 1 到位 11 的 BMCR 寄存器,但在异常情况下,无论我写多少次,它没有成为 1。

向第 11 位写入 1 后、不会立即执行软件复位。

此致、

ITO

尊敬的 Harsha：

这项调查是否有任何进展？

此致、

ITO

请在 Linux 运行时检查 PHY Strap 配置、这可能与 POR 场景不同、为了确保 PHY 硬件 strap 配置正确完成以初始化 PHY、这一点很重要。

您是否跟进了这一点？

您好 PratheeshGangadhar、

抱歉、我忘记提及这个。 当在正常运行期间检查 STRAP_STS 寄存器值时、它们为 0x0000 和 0x0010。

PHY 地址分别设置为 0000 和 0001、因此我认为上述读取值是正确的。

此致、

ITO

尊敬的 K.Z：

日志中的记录 5707.Error.txt 您已经分享过、我怀疑与 PHY 的 MDIO 通信不正确。 PHY 寄存器值在此处似乎无效。

此致、

尊敬的 Harsha：

我调查了 MDIO 通信、

上电后、DP83869HM 正确初始化。
但是、重新启动 AM6442 后、大多数 MDIO 寄存器读取值变为 0x1140、因此无法实现正确的初始化。
当仅对 AM6442 进行复位、或当 AM6442 和 DP83869HM 同时复位然后释放时、会发生问题。

我确认了 STRAP_STS 寄存器将地址设置为 0x0000 和 0x0001、并验证了这些地址在重新启动期间不会发生变化。
但重新启动后、STRAP_STS 寄存器值也变为 0x1140、因此我无法确认 0x0000 和 0x0001。
也就是说、在重新检查异常的寄存器转储值时、似乎只有寄存器 0x0D（REGCR 寄存器）被正确读取。
当我在问题发生后对此寄存器执行了写入访问时、该值发生了变化、写入的值被成功读回。
此外、当我将 0x0D 的值更改为 0x001F 并修改 0x0E（ADDAR 寄存器）的值时、新值被正确读回。
由此、我相信 PHY 地址本身在重新启动后没有改变。

接下来、我添加了日志以检查 CUST_PHY_dp83869.c 中的初始化过程是否在重新启动后被正确调用、并在调用 CUST_PHY_DP83869_setPowerMode 之前调查了 MDIO 通信是否成功。

首先、我在 CUST_PHY_dp83869.c 中定义的每个函数开头添加了日志输出、以验证正常和异常情况下会出现哪些日志。
此外、对于包括等待特定位值发生变化之前的无限循环的功能（类似于 CUST_PHY_DP83869_setPowerMode）、我添加了循环退出时寄存器值的日志输出。

因此、即使在异常情况下、也会以与正常情况相同的顺序调用相同的函数、因此初始化过程似乎在重新启动后被正确调用。

但是、请查看 CUST_PHY_DP83869_softwareRestart 函数的日志输出：

• 在正常情况下： ...Restart: GEN CTRL Val: 0x0
• 在异常情况下： ...Restart: GEN CTRL Val: 0x1140

根据数据表第 7.6.1.27 节、GEN_CTRL 寄存器（偏移= 1Fh）、GEN_CTRL 寄存器中只有位 15 和 14 有效。
CUST_PHY_DP83869_softwareRestart 中的无限循环会检查位 14 是否为 0、因此即使读取寄存器值为 0x1140、循环也可能会退出。

因此、由于正在检查该位、该过程在达到 CUST_PHY_DP83869_setPowerMode 之前不会卡在无限循环中、但异常值 0x1140 出现在之前。

从上述结果可以看出、当 AM6442 重新启动时、DP83869HM 中的大多数 MDIO 寄存器此时似乎停止正常运行。
但是、寄存器 0x0D 工作正常、根据其值、0x0E 似乎也可以正常工作。

目前、我怀疑如果 AM6442 和 DP83869HM 之间通过 MII 或 MDIO 进行的通信中断一段时间、DP83869HM 就会启动故障。

你有什么想法或建议吗?

此致、

ITO

尊敬的 Harsha：

请告诉我您的意见。

此致、

ITO

[引用 userid=“584182" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1588218/am6442-bit-11-of-the-bmcr-register-in-the-dp83869hm-does-not-become-1/6136407 ]AM6442 和 DP83869HM、通过 MII 或 MDIO 中断一段时间[/报价]

这是否可以通过示波器监控 MDIO 信号进行确认？ 我仍然怀疑这里没有正确初始化 PHY

发生此问题后、除非重新打开电源、否则它通常无法恢复。

对于此处重点介绍的两个错误场景、您能否探测 PHY 硬件配置 (strap) 引脚以确保它们处于所需状态

你好  ratheeshGangadhar、

感谢您的答复。

我将使用示波器进行检查。
我已经发送了寄存器转储错误、扩展寄存器访问测试
和 PHY 日志到您的私人消息中。 请查看它们。

此致、

ITO

您好 PratheeshGangadhar、

是否可以通过示波器监控 MDIO 信号来进行确认？ 我仍然怀疑此处 PHY 未正确初始化

两个都正常。
我认为、在硬件搭接引脚中、唯一影响整体 MDIO 访问的引脚是 PHY_ADD 设置。 不过、是否有任何其他硬件 strap 配置引脚可能导致 MDIO 读取值几乎始终变为 0x1140？ 如果存在这样的引脚、可能是解决问题的线索、因此请告诉我。
此外、我还通过在重新运行 EtherCAT 示例程序之前插入不同程序的执行来执行额外的验证、步骤如下：

・停止 R5F 内核
・在 R5F 内核上加载并执行不访问 PRU 内核或 EtherCAT PHY 的程序
・再次停止 R5F 内核、然后加载并执行 EtherCAT 采样程序

三次检查后、该异常全部发生三次。
该异常不是由读回 BMCR 寄存器（读取值 0x1140）的位 11 引起的先前无限循环、
但是、与正常运行相比、日志输出之间的间隔要长得多。
具体而言、通过 PRU 固件访问 PHY 寄存器需要几十秒甚至几百秒的时间。
为了读取 PHY 寄存器、使用函数 CUST_PHY_readReg ()；而对于写入、函数 CUST_PHY_writeReg ()。
日志输出之间、这些函数用于访问 PHY 寄存器、
但是、由于这些函数仅以二进制文件的形式提供、因此我们不知道什么处理导致了延迟。
此外、不仅是在重新运行 EtherCAT 示例程序之前插入执行不同程序时、还在停止 R5F 内核并在加载和执行 EtherCAT 示例程序之前等待大约一分钟时，所有三次尝试中都发生了相同的异常 — 日志输出之间的间隔很长。
另一方面、当停止 R5F 内核并立即加载和执行 EtherCAT 样本程序时、所有三次尝试在重新加载后都显示正常的日志输出。
从该额外验证的结果可以看出、一旦 DP83869HM 通过 MDIO 和 MII 建立通信、如果 MAC 停止而不复位、则 DP83869HM 会发生故障、并且它无法恢复。

此致、

ITO