[参考译文] AM2432：AM243x PROFINET IRT 固件：什么会触发 rxOverSizedFrames 获取来自直接连接的 Siemens simit 模块的有效帧？

尊敬的 Yanyves G é n é reux,

您当前正在读取哪个偏移或变量来检查 rxOverSizedFrames 计数？

此致、

Laxman

你好、Laxman、

我们通过 TI 自己的 SDK API 读取该值— ICSS_EMAC_readStats() From source/networking/icss_emac/source/icss_emac_statistics.c、后者 memcpy是 ICSS_EMAC_FW_STAT_SIZE 从每端口 PRU DRAM 统计块中的一个字节到 ICSS_EMAC_PruStatistics 中定义的结构中 source/networking/icss_emac/icss_emac.h。

在该结构中, rxOverSizedFrames 是 uint32_t 0x80 从统计块的开头偏移的第 33 个字节。

统计块库位于：

• 端口 1： pru0DramBase + ICSS_EMAC_FW_STATISTICS_OFFSET
• 端口 2： pru1DramBase + ICSS_EMAC_FW_STATISTICS_OFFSET

使用 ICSS_EMAC_FW_STATISTICS_OFFSET = 0x1F00 和 ICSS_EMAC_FW_STAT_SIZE = 0x90 (PROFINET build)、在中定义 source/industrial_comms/profinet_device/icss_fwhal/firmware/icss_emac_mmap.h。

在我们的目标 (AM2432, ICSSG0 实例, pru0DramBase = 0x30000000 pru1DramBase = 0x30002000) 上,解析为绝对地址:

• 端口 1 rxOverSizedFrames： 0x30001F80
• 端口 2 rxOverSizedFrames： 0x30003F80

我们还通过每端口寄存器转储确认、统计块位于预期位置（对于 PRU0 和 PRU1）statistics @0x30001F00 @0x30003F00 。

在面向 Siemens 的端口上、每个 DCP Ident-Req-all 周期 rxBcast rxMcast rxUcast 的此计数器递增~128、而对于相同的帧、匹配的//计数器保持为 0。 同一结构（，，，，）中的所有 MAC 级错误计数器SFDError macRxError rxCRCFrames rxMisAlignmentFrames rxUnderSizedFrames始终保持为 0。

如果您想要这些地址的原始 PRU DRAM 转储、或者想了解任何其他详细信息、请告诉我。

谢谢、Yanyves G é n é reux

尊敬的 Yanyves G é n é reux,

RxOversize 和 RxUndersize 帧计数统计信息当前未在固件中启用。 此外、固件的统计存储器布局与 ICSS-EMAC 统计存储器配置不一致 — 超大计数器位于相对偏移 0x1F78、小计数器位于 0x1F7C。

我们将修复固件统计信息偏移、以便与下一版本中的 ICSS-EMAC 相匹配。

谢谢。此致、

Laxman

你好、Laxman、

感谢您的回答、很高兴知道布局有问题、如果您要在下一个版本中修复它、这是完美的。

我有一个关于偏移 0x30001F80 和 0x30003F80 的问题、如果这些计数器不是什么、它们是什么 rxOverSizedFrames (nor RxUndersized)？

再次感谢您

此致

Yanyves

您好 Yanyves、  

在当前存储器配置中、0x1F80 偏移量指示 Rx CRC 错误计数。

此致、

Laxman

您好、Laxman：

非常感谢您澄清这一点—这是我们调查的一个重要发现。 因此、我们一直跟踪为“rxOverSizedFrames“（结构偏移 0x80、绝对值 0x30001F80/0x30003F80）ICSS_EMAC_PruStatistics 的计数器实际上是 rxCRFrames 。 这完全改变了我们的诊断：来自直接连接的 Siemens 器件的帧未通过 PRU MAC 的 CRC 验证、并未因过大而被拒绝。

这与我们所观察到的操作一致—在 Siemens 设备的上游插入受管以太网交换机可“修复“症状、因为交换机终止并使用新计算的 FCS 重新传输每个帧。 由于交换机本身不会丢弃帧、因此 CRC 必须在线路上实际有效、这意味着线路和 PRU MAC 之间的某个位置发生位损坏。

为了便于参考、 我们还在运行相同 PRU 固件的 TI AM243x 评估板（带有 DP83867CR PHY）上重现了此确切症状。 我们的生产板使用不同的 PHY (DP83826E)。 两个不同电路板上的两个不同 PHY 芯片在相同 PRU 固件下都表现出症状、这表明问题出在 PRU/MII 层、而不是特定于 PHY。

几个后续问题：

1. 中的其他字段是否 ICSS_EMAC_PruStatistics 也与固件布局不一致？ 到目前为止 SFDError,我们的调查依赖于, macRxError, rxCRCFrames （我们现在知道这实际上是别的东西） rxMisAlignmentFrames,和 stormPrevCounter* 所有读数 0—但如果这些结构偏移也映射到固件中的不同字段,我们的一些结论需要重新验证。 您能否分享 在提供对齐修复之前我们应该依赖的固件端统计存储器布局（偏移量→计数器名称）？

2. 即使 PRU MAC 在相同传入帧上报告 CRC 故障、受影响端口上的 PHY 也会报告零个 PHY 侧错误（接收错误计数器，FCS 错误计数器、信号检测状态等。DP83826E 和 DP83867CR 上均清除）。 PHY 在将帧传递到 MII 之前独立验证 FCS 的预期行为、或者 FCS 验证是否仅在 PRU MAC 层进行？ 我们试图了解线路和 PRU MAC 之间发生位损坏的位置、以及是否存在任何 PRU 共享存储器或 MII 层设置、这些设置可能会增加对 Siemens 器件发出的任何信号的耐受性。

再次感谢—知道这是一个 CRC 问题、而不是一个过大的问题、可以为我们提供更具体的调查方向。

此致、
Yanyves

您好 Yanyves、

1) 下面是固件中使用的实际统计偏移量。 大多数调试偏移在当前基线中被禁用。

/cfs-file/__key/communityserver-discussions-components-files/791/Firmware_5F00_statistics_5F00_offset.txt

2) FCS 验证仅在 PRU MAC 层中发生一次。  

此致、

Laxman

您好、Laxman：

非常感谢您详细的布局、这对此进行了非常详细的说明。 这意味着、我们在之前的诊断中一直依赖的几个“零“值对应于当前禁用的固件计数器。 具体而言、结构字段 SFDError macRxError、 rxMisAlignmentFrames、、、、 rxCRCFrames rxUnderSizedFrames droppedPackets、 txOverFlow txUnderFlow 所有映射到您的表中列出为禁用的固件偏移—因此我们读取的零是“计数器未实现“、而不是“无错误“。 我们真正可以看到的唯一错误计数器是 FW 偏移 0x1F80 (RX_CRC_COUNT) 的错误计数器、它在受影响的端口上一直递增。

要回答后续问题：

1) MII 或 RGMII？

MII。在我们的 SysConfig 中：

hsr_prp1.icss_emac[0].phyToMacInterfaceMode = scripting.forceWrite("MII");

连接的端口与链路伙伴协商 100Mbps 全双工模式 (BMCR = 0x3100、PHYSTS 报告 Link / FD / AutoNegCplt / Signal_DET / Dscr_lock)。

2) ICSSG 存储器转储

我们正在运行的目标 (ICSSG0 实例、base 0x30000000) 的摘录来自仅隔离式测试（PC 断开连接、仅连接 simit 模块、在 ICSS_EMAC_PORT_1/PRU0 上）：

ICSSG base addresses:
  baseAddr            0x30000000
  miiRtCfgRegBase     0x30032000
  miiMdioRegBase      0x3001FF00
  pru0IramBase        0x30034000  size 16384
  pru1IramBase        0x30038000  size 16384
  sharedDramBase      0x30010000  size 65536
  txPru0IramBase      0x3000A000  size 8192
  txPru1IramBase      0x3000C000  size 8192

miiRtCfg register dump (@ 0x30032000):
  RXCFG0          (0x0000) = 0x00000217
  RXCFG1          (0x0004) = 0x0000021F
  TXCFG0          (0x0010) = 0x00001803
  TXCFG1          (0x0014) = 0x00001903
  TX_IPG0         (0x0030) = 0x00000017
  TX_IPG1         (0x0034) = 0x00000017
  RX_FRMS0        (0x0040) = 0x05F1003F   (max 1521 / min 63 bytes)
  RX_FRMS1        (0x0044) = 0x05F1003F   (max 1521 / min 63 bytes)
  RX_PCNT0        (0x0048) = 0x000000E1
  RX_PCNT1        (0x004C) = 0x000000E1
  RX_ERR0         (0x0050) = 0x00000002   (SIMIT-facing port)
  RX_ERR1         (0x0054) = 0x00000000   (no link partner)
  RX_FIFO_LEVEL0  (0x0060) = 0x00000000
  RX_FIFO_LEVEL1  (0x0064) = 0x00000000
  TX_FIFO_LEVEL0  (0x0068) = 0x00000000
  TX_FIFO_LEVEL1  (0x006C) = 0x00000000

PRU0 DRAM (@0x30000000) — Port 1 firmware data (SIMIT-facing, link up):
  version    @0x30000000 = 0x00000707
  version2   @0x30000004 = 0x80110006
  feature    @0x30000008 = 0x0003421A  (MODE | STORM_PREV | MRP | PTCP | QUEUES | PROFINET | DCP_FILTER)
  phySpeed   @0x30001F9C = 100
  portStatus @0x30001FA0 = 1
  portControl @0x30001FA6 = enabled (0x01)
  portMac    @0x30001FAA = 00:A0:91:CA:AF:00

PRU1 DRAM (@0x30002000) — Port 2 firmware data (no link partner during this test):
  version, version2, feature word identical to PRU0 (feature = 0x0003421A);
  phySpeed=0, portStatus=0, portControl=disabled.

如果有用、我可以发送完整转储文件（包括整个 MDIO 寄存器块、Profinet RTC/PPM 子块和 TX-PRU MDIO 固件部分）-告诉我。

3) 是否所有简单的帧都有 CRC 问题?

是—我们有一个干净的隔离测试确认它。 在 ICSS_EMAC_PORT_1/PRU0 上仅连接简单模块（无 PC，无其他对等）的情况下、稳定状态后台窗口中绝对 CRC 地址 0x30001F80 处的计数器：

• RX_BYTE_CNT_OFFSET (FW 0x1F1C、主机结构 rxOctets)： 0 →无成功接收的字节
• RX_UC_FRAMES_OFFSET (FW 0x1F18、主机结构 rxUcast)： 0 →没有成功接收的单播帧
• RX_CRC_COUNT_OFFSET (FW 0x1F80、主机结构 rxOverSizedFrames)： 162
• RX_ERR0 (miiRtCfg @0x30032050)： 2.

162 个 CRC 错误完全来自 simit 模块的后台 PROFINET 流量—PN-PTCP DelayReq 的帧速率为~1 帧/秒、LLDP 的帧速率为~1 帧/ 5 秒、在干净重启后的几分钟内累积、在此窗口期间不会触发 DCP Ident-Req-all。 因此、这不是突发现象—它在较慢的合理间隔速率以及各种帧类型和帧 ID（PTCP、LLDP、DCP 的行为方式都是相同的）上发生。

引人注目的观察结果是比率： 在通过简单端口接收到的~162 帧中、MII RT 硬件层仅标记了 2 个有错误 (~1.2%)、但 PRU MAC 的 CRC 校验完全拒绝了其中的 2 个帧。 因此、MII RT 层认为基本上所有接收到的字节都是干净的、但 CRC 验证步骤在每个帧上仍然失败。 在 MII RT 和 PRU MAC 的 CRC 引擎之间引入了差异。

在 simit 模块和 AM243x 之间插入任何受管以太网交换机可以完全清除 CRC 故障：然后正常转发帧、并且（在 PC 重新连接的情况下）PC 端 PROFINET 控制器会接收所有响应。

我们方面的一个后续行动： 鉴于 SFD_ERROR、RX_ERROR、RX_UNDIRECTION、RX_UNOGEN 和 RX_UNDERSIZE 当前在固件基线中被禁用、我们无法判断 CRC 故障是唯一的症状、也无法判断它之前是否存在简单地不计入的早期成帧问题（SFD 误检测，失准等）。 是否有一种固件调试构建（启用了这些附加计数器）或一种在运行时启用这些计数器的方法、我们可以使用该固件来进一步确定 PHY 的 MII 接口和 PRU MAC 的 CRC 校验之间引入了位损坏的位置？

再次感谢—布局说明非常有用。

此致、

Yanyves

您好 Yanyves、

如果有用、我可以发送完整转储（包括整个 MDIO 寄存器块、Profinet RTC/PPM 子块和 TX-PRU MDIO 固件部分）—告诉我。

是的、请分享完整的 ICSSG 存储器转储、主要从存储器地址 0x300B2000 到 0x300B4000。

您是否也可以在两种情况下共享 Wireshark 日志？

a) 网络中的仿真和 DUT。

b) 在网络中进行仿真、交换机和 DUT。 在这种情况下、我们想确认通过 simit to Switch 发送的帧是否与交换机发送到 DUT 的帧完全相同。

是否有一种固件调试构建并启用了这些额外的计数器、或者一种在运行时启用这些计数器的方法、我们可以使用它来进一步确定 PHY 的 MII 接口和 PRU MAC 的 CRC 检查之间引入位损坏的位置？

目前、我们  尚未 在固件中实现大多数调试计数器。 仅存在 RX_OMARN 和 RX_UNDERSIZE、但被禁用。 如果需要、我们可以启用此功能以进行进一步调试。 但是、我们希望通过请求的上述日志、我们能够更好地理解该问题。

此致、

Laxman

您好、Laxman：

就是这样—你的序言假设得到证实,这个问题得到了完全解决。

清除 MII_RT RX_PCNT0/1 寄存器 (0x30032048/0x3003204C 现在读取 0x00000001、即 RX_MAX_PCNT=0、RX_MIN_PCNT=1) 中的 RX_MAX_PCNT 字段后、简单器件的帧将完全接收到直接连接的 PROFINET 端口上（两个正向板之间没有开关）和现在两个正向板的 DCP 响应之间的正常状态。

在面向 simit 的端口上之前/之后：

因此、简单的器件发射的前导码长于默认的 RX_MAX_PCNT (14)、并且 MII_RT 前导码截止逻辑强制将帧的最大值移位、从而在 PRU MAC 上产生 CRC 错误。 清除 max-preamble 检查会完全解析它。

关于使这一永久化的几个后续问题：

1. 设置 RX_MAX_PCNT = 0 是否为安全且建议的永久配置、或者您是否建议使用特定的非零值来适应更长的 simit 前导码、同时保留一些上限保护？

2. 禁用 max-preamble 检查是否有我们应该注意到的任何副作用、例如、对 RT/IRT 计时、对表现良好的对等方的 preamine-cut 行为或对另一个端口产生影响？

3. 这是否会在未来版本的固件中解决、或者将来是否从应用程序配置 RX_PCNT 是预期的方法？ 如果是后者、它是否有 LLD/Sysconfig 设置、或者我们是否应该在 ICSS_EMAC_open () 之后直接继续写入寄存器？

非常感谢你的指针—这解开了我们。

此致、Yanyves

您好 Yanyves、

很高兴知道此问题已在您的设置中得到解决。

• 设置 RX_MAX_PCNT = 0 是否为安全且建议的永久配置、或者您是否建议使用特定的非零值来适应更长的 simit 前导码、同时保留一些上限保护？

• 禁用 max-preamble 检查是否有我们应该注意到的任何副作用、例如、对 RT/IRT 计时、对表现良好的对等方的 preamine-cut 行为或对另一个端口产生影响？

• 这是否会在未来版本的固件中解决、或者将来是否从应用程序配置 RX_PCNT 是预期的方法？ 如果是后者、它是否有 LLD/Sysconfig 设置、或者我们是否应该在 ICSS_EMAC_open () 之后直接继续写入寄存器？

提供上述问题的答案：

1) 将 RX_MAX_PCNT 设置为 0 是安全的配置、因为前导码计数不限于 8 个字节。  

2) 我们不期望在禁用此检查时有任何副作用。 但是、我们将在这边运行一些测试、以确认没有因配置更改而导致任何问题。

3) 我们将计划 在即将发布的版本中包含此修复程序。

此致、
Laxman

您好、Laxman：

非常感谢您在整个调查过程中提供的帮助以及我们后续问题的清晰答案。

若要关闭循环：清除两个端口上的 RX_MAX_PCNT 字段可完全解决该问题。 现在可以接收 Siemens simit 帧、没有 CRC 错误、并且可以在电路板的两个端口之间正确转发 DCP 响应、之间无需切换。 你对序言长度的见解是正确的,节省了我们很多时间。

我们特别感谢：

• 澄清实际的固件统计存储器布局（RX_CRC_COUNT 与 RX_OMNIKATE 偏移）、这是理解我们一直在查看 CRC 错误的关键；
• 确认 RX_MAX_PCNT = 0 是一个安全配置、没有预期的副作用；
• 计划在即将发布的固件版本中包含此修复程序。

我们现在已经从应用程序中应用了寄存器写入、并将在固定固件可用时将其删除。 我们将密切关注此次发布。

再次感谢您的响应和全面支持。

谨致问候、Yanyves G é n é reux