企业官网建设流程全解析

1. 项目概述与核心价值

在工业自动化、运动控制或者任何对网络通信延迟有苛刻要求的嵌入式场景里，处理器内核（如ARM Cortex-A）处理协议栈的软件开销常常成为性能瓶颈。为了突破这个限制，德州仪器（TI）在其Sitara AM系列处理器中集成了一个名为PRU-ICSS（可编程实时单元和工业通信子系统）的协处理器。这个子系统内的MII_RT（媒体独立接口实时）模块，正是实现微秒级甚至纳秒级网络数据处理的硬件加速引擎。它不是一个简单的接口转换器，而是一个深度集成在PRU指令流水线中的数据搬运与预处理中心。

本文要拆解的，就是MII_RT模块里最核心的“高速公路系统”——RX/TX数据路径及其配套的FIFO（先进先出队列）机制。很多开发者初次接触TRM（技术参考手册）时，面对RX L1、RX L2、TX L1、TX L2这些名词，以及复杂的寄存器位域，容易感到困惑：它们到底是如何串联工作的？为什么需要这么多级缓冲？PRU又是如何以近乎零延迟的方式“触摸”到网络数据的？我将结合手册中的关键图表和寄存器描述，把这些硬件数据流“翻译”成软件工程师和系统架构师能直观理解的逻辑模型，并分享在实际编程和调试中积累的实战经验。无论你是正在评估AM261x用于下一代实时网络设备，还是正在为其编写底层PRU固件，理解这套数据路径的运作细节，都是实现高性能、高可靠性设计的基础。

2. MII_RT模块架构与数据路径总览

在深入细节之前，我们需要建立一个顶层的架构视图。MII_RT模块是PRU-ICSS与外部PHY芯片之间的桥梁，它负责处理MII、RMII、RGMII、SGMII等多种物理层接口的时序，并将数据以最有效的方式交付给PRU核心，或者从PRU核心接收数据发送出去。

整个数据流可以清晰地划分为接收（RX）和发送（TX）两条独立路径，每条路径又根据性能需求提供了不同的“车道”选择。

2.1 接收路径（RX Path）的两种模式

接收路径的核心目标是将从PHY源源不断到来的串行比特流，转换成PRU能够直接处理的并行数据，并在此过程中进行错误检测和状态标记。

路径一：低延迟直通模式 (RX MII Port → RX L1 FIFO → PRU)这是最直接、延迟最低的路径。数据从MII接口进入后，首先进入一个32字节深的RX L1 FIFO。关键在于，FIFO中的第一个数据字节会自动映射到PRU核心的R31寄存器的特定比特位（BYTE0, BYTE1）上。这意味着PRU无需执行显式的“读”指令，最新的接收数据就已经在寄存器里待命了。PRU通过检查R31中的状态位（如DATA_RDY），确认数据有效后，可以直接对R31中的数据进行操作。处理完后，通过向R31的命令接口写入POP指令，将数据从FIFO中移除，新的数据会自动填充进来。这种模式实现了“单字在途”，延迟极低，但要求PRU firmware必须跟得上数据到达的速率，否则会导致FIFO溢出。

路径二：高吞吐量缓冲模式 (RX MII Port → RX L1 FIFO → RX L2 Buffer → PRU)当数据包较大，或者PRU需要批量处理数据时，直通模式可能显得局促。此时可以启用RX L2缓冲区。这是一个64字节的“乒乓缓冲区”（Ping-Pong Buffer），分为两个32字节的Bank。数据从RX L1 FIFO被搬运到RX L2的一个Bank中暂存。PRU则通过高效的XFR（外部传输）读指令，一次性地将整个Bank的数据（最多32字节）和对应的状态信息，批量加载到一组通用寄存器（R2-R13）中。这样，PRU可以在一段相对宽松的时间内处理这32字节的数据，而RX L1 FIFO则可以继续接收后续数据并填充另一个Bank。这种“多字在途”的机制大大提升了吞吐量和firmware处理的灵活性。

2.2 发送路径（TX Path）的数据组装

发送路径的逻辑是接收路径的逆过程，核心在于如何灵活地组装要发送的以太网帧。

数据来源的混合与选择发送数据可以来自两个源头：

1. PRU核心自身：PRU将待发送数据写入R30寄存器，然后通过R31命令接口的PUSH操作，将数据压入TX L1 FIFO。
2. 接收路径的直通：接收到的数据可以直接从RX L1 FIFO转发到TX L1 FIFO，实现类似交换机的“直通转发”。

更有趣的是，通过**TX掩码（TX Mask）**机制，PRU可以精细控制每一字节数据是来自R30（本地生成）还是来自RX L1 FIFO（转发）。这为实现协议修改、标签插入/移除等网络处理功能提供了硬件级的便利。

两级发送缓冲：TX L2与TX L1 FIFO为了更高效地组织发送帧，特别是处理VLAN、HSR（高可用性无缝环网）标签等复杂情况，发送路径引入了TX L2 FIFO。这是一个64字节的缓冲区，PRU可以一次性向其中写入最多64字节的完整或部分帧数据。TX L2 FIFO会按照配置，自动处理标签的插入或移除，然后将处理后的数据流送入40字节的TX L1 FIFO，最终由硬件逻辑按MII时序发送出去。TX L1 FIFO更靠近物理接口，负责最终的节奏控制，包括帧间隔（IPG）的满足。

2.3 核心设计思想解读

理解这套设计，需要把握几个关键点：

• 硬件加速与软件灵活性的平衡：错误检测（CRC、帧长）、状态标记（SOF、EOF）等固定任务由硬件完成，结果实时更新在状态位中。数据内容的处理、转发决策、协议解析等灵活任务则由PRU firmware完成。
• 延迟与吞吐量的权衡：RX L1直通模式追求最低延迟，适用于对每个数据包都需立即响应的场景（如EtherCAT的分布式时钟同步）。RX L2缓冲模式牺牲少许初始延迟，换取更大的处理带宽和更宽松的响应时间，适用于处理大数据包或进行复杂数据处理的场景。
• 资源与效率的考量：使用小而快的FIFO（L1）进行速率匹配和临时暂存，使用大而结构化的缓冲区（L2）进行批量搬运。PRU通过特殊的XFR指令和Broadside接口访问L2缓冲区，实现了接近内存带宽的数据加载效率。

3. 接收路径深度解析与实战编程

3.1 RX L1 FIFO直连模式：极速响应的实现

在这种模式下，PRU与网络数据流是“贴身肉搏”。数据流经RX L1 FIFO这个32字节的“小水池”时，第一个字节就立刻出现在了PRU的R31寄存器中。

3.1.1 R31寄存器：数据与状态的窗口R31在此模式下扮演了双重角色：它既是数据寄存器（低16位），也是状态和控制寄存器（高16位）。当我们读取R31时，硬件返回的是当前时刻FIFO出口的数据和对应的链路状态。

关键状态位及其使用场景：

• DATA_RDY(Bit 16)：这是最重要的“数据就绪”标志。为1表示R31[7:0]和/或R31[15:8]中有新的有效数据。PRU firmware应首先检查此位。
• BYTE_RDY(Bit 17) /WORD_RDY(Bit 18)：分别指示低字节（BYTE0）或整个字（BYTE1&BYTE0）数据有效。它们与DATA_RDY协同，告诉firmware当前可安全读取的数据宽度。
• RX_SOF(Bit 22) /RX_SFD(Bit 21) /RX_EOF(Bit 20)：帧起始、帧起始定界符、帧结束标志。它们是硬件检测到的物理层事件，对于帧边界识别至关重要。例如，RX_SFD检测到0xD5序列，标志着前导码结束，真正的以太网帧开始。
• RX_ERROR(Bit 19) /ERROR_CRC(Bit 24) /RX_ERR(Bit 25)：错误指示位。RX_ERROR是一个总错误标志，ERROR_CRC指示CRC校验失败，RX_ERR指示MII_RXER信号有效（如物理层错误）。

3.1.2 数据弹出（POP）操作与流控制PRU处理完R31中的数据后，必须通过写入R31��命令位来“弹出”数据，以便为新数据腾出空间。命令位是R31的写接口，与读接口是独立的。

• RX_POP8(对应写入操作)：弹出1个字节（BYTE0）。执行后，FIFO指针前移1字节，新的BYTE0数据（原BYTE1）和状态会更新到R31中。
• RX_POP16(对应写入操作)：弹出2个字节（BYTE1和BYTE0）。这是更常用的操作，因为MII接口通常以半字（16位）为单位接收数据。

重要提示：手册中明确提到，从发出RX_POP8/16命令到BYTE_RDY/WORD_RDY状态位更新，有2个PRU时钟周期的延迟。这意味着firmware在发出POP指令后，必须等待至少2个周期再去读取BYTE_RDY/WORD_RDY位来判断新数据是否就绪。立即读取会得到陈旧的状态，导致程序逻辑错误。一个常见的做法是在POP指令后插入两条NOP指令。

3.1.3 溢出处理与FIFO复位RX L1 FIFO只有32字节。如果PRU firmware处理速度跟不上数据到达速度（例如，在复杂计算中循环太久），FIFO就会溢出。

• 溢出后果：发生溢出的数据帧会被硬件自动丢弃，因为帧已经不完整。同时，模块会向系统事件管理器（INTC）触发一个PRU<n>_RX_OVERFLOW事件。
• 软件应对：PRU firmware应该通过轮询或中断的方式监控这个系统事件。一旦检测到溢出，必须通过R31命令接口发出RX_RESET命令来清除FIFO的溢出状态，并丢弃当前损坏的帧。之后，才能重新开始接收新的帧。
• 编程建议：在编写高吞吐量应用时，应将POP操作和数据处理的循环设计得尽可能高效。如果单次处理逻辑复杂，应考虑启用RX L2缓冲区，将数据批量取回后再处理。

3.2 RX L2缓冲区模式：批量处理的艺术

当启用RX L2后，数据流变成了：MII → RX L1 FIFO → RX L2 Buffer → PRU。RX L1 FIFO在这里主要起一个短暂的暂存和速率缓冲作用，数据会被尽快搬运到64字节的RX L2缓冲区中。

3.2.1 乒乓缓冲区（Ping-Pong Buffer）机制RX L2缓冲区被划分为两个独立的32字节Bank（Bank 0和Bank 1）。其工作流程如下：

1. 硬件将来自RX L1的数据写入当前活动的Bank（例如Bank 0）。
2. 当Bank 0写满32字节，或者一个帧结束（EOF）时，硬件会自动切换写指针到另一个Bank（Bank 1），并继续写入。同时，它会通过状态位告知PRU，Bank 0的数据已就绪。
3. PRU firmware通过XFR读指令（指定Device ID为20或21），将整个Bank 0的数据和状态批量加载到自己的寄存器文件（R2-R13）中。
4. 在PRU处理Bank 0数据的同时，硬件可以继续向Bank 1写入新数据。
5. 处理完Bank 0后，PRU通过某种方式（如清除状态标志）通知硬件该Bank可被复用。当Bank 1就绪时，PRU再读取Bank 1，如此循环。

这种机制有效地将数据生产（硬件接收）和数据消费（PRU处理）解耦，允许硬件持续接收而不必等待PRU，也给了PRU一段完整的时间窗口来处理一批数据。

3.2.2 XFR指令与寄存器映射访问RX L2不是通过普通的加载/存储指令，而是通过PRU特有的XIN/XOUT指令（统称XFR）。这类似于DMA，但延迟更低，是PRU与内部模块高速交换数据的关键。

• Device ID：20对应Bank 0，21对应Bank 1。执行XIN指令时，指定对应的Device ID，即可将目标Bank的数据和状态数组加载到PRU的寄存器中。
• 数据与状态数组：
  • 数据数组：存储在R2到R9这8个寄存器中。每个寄存器32位（4字节），总共32字节。数据按照接收顺序，从R2的字节0开始依次填充。
  • 状态数组：存储在R10到R13这4个寄存器中。每16位数据（2字节）对应一个8位的状态字节。状态字节包含了该16位数据对应的ERROR_CRC、RX_EOF、STATUS_RDY等关键信息。
• 写指针寄存器R18：PRU可以读取R18的低6位来获取当前的写指针位置。这个指针指示了硬件正在向哪个Bank的哪个字节写入数据。软件通过比较读指针（自己维护）和写指针，可以知道有多少新数据到达。

3.2.3 背压（Backpressure）与数据一致性手册中提到一个重要概念：在RX_L2_EOF事件发生到RX_L2_DONE事件之间，RX L2会对RX L1施加背压。这意味着，当一个帧的数据正在从RX L1向RX L2搬运的收尾阶段，RX L1会暂停接收新数据，防止新帧的数据破坏当前帧在L2中的完整性。 对于PRU firmware而言，必须在硬件覆写一个Bank之前，将该Bank的数据读取并处理完毕。这通常通过监控状态寄存器中的STATUS_RDY位或RX_EOF位来实现。一旦检测到Bank就绪（例如STATUS_RDY置位），应立即发起XFR读取操作。

实战心得：RX L2模式下的编程模型

1. 初始化：配置CFG寄存器启用RX L2模式，初始化软件维护的读指针。
2. 主循环：轮询或通过中断感知数据就绪。可以通过检查R31的某个通用状态位（需配置映射），或者更高效地，在XFR读取状态数组后检查STATUS_RDY。
3. 数据读取：使用XIN指令，根据当前该读取的Bank（通过一个软件变量切换），将Device ID 20或21的数据和状态加载到R2-R13。
4. 数据处理：解析状态数组，定位帧的起始和结束。根据数据数组进行协议解析、内容修改或转发决策。
5. 指针更新与切换：处理完毕后，更新软件读指针，并切换Bank索引，准备读取下一批数据。如果处理的是帧的结尾，可能需要执行一些清理工作，如发出RX_L2_DONE命令（通过写特定寄存器）来释放背压。

4. 发送路径深度解析与帧构造技巧

发送路径的核心任务是按照以太网标准，构造出正确的字节流，并通过MII接口发送出去。MII_RT模块提供了从简单到复杂的多种构造方式。

4.1 基础发送：PRU直接推送数据

在最简单的模式下，PRU通过R30和R31直接操作TX L1 FIFO。

1. 准备数据：将待发送的字节数据写入R30寄存器的低8位或低16位。
2. 设置掩码（如果使用）：如果需要混合RX数据，设置R30的高16位作为TX掩码。0xFF表示对应字节使用R30的数据，0x00表示使用来自RX L1 FIFO的数据。
3. 执行推送：通过写R31命令接口的TX_PUSH8或TX_PUSH16位，将R30中的数据（根据掩码混合后）压入TX L1 FIFO。
4. 重复：重复步骤1-3，直到整个帧的数据（包括可能的填充字节）都写入FIFO。
5. 结束帧：在写入最后一个数据字节后，通过设置R31的TX_EOF位来通知硬件帧结束。硬件会自动计算并追加4字节的CRC。

关键限制：TX L1 FIFO只有40字节深度，且包含前导码。这意味着对于超过最小帧长（64字节）的帧，PRU必须紧密配合，在FIFO有空间时立即写入新数据，否则可能导致发送欠载（Underflow）。这给firmware的实时性带来了很大压力。

4.2 高级发送：使用TX L2 FIFO与自动处理

为了减轻firmware负担并支持高级功能，应使用TX L2 FIFO。

4.2.1 TX L2 FIFO的工作流程

1. 批量加载：PRU使用XFR写指令（Device ID 40），一次性将最多64字节的帧数据写入TX L2 FIFO。可以写入1到64字节之间的任意长度，数据在R2-R17寄存器中LSB对齐存放。
2. 自动处理：硬件根据TX_L2_ENABLE等配置位，自动从TX L2 FIFO中读取数据，进行可选的VLAN/HSR标签插入或移除操作，然后将处理后的数据流送入TX L1 FIFO。
3. 状态监控：PRU可以读取状态寄存器（如TXL2ByteSentCount）来了解发送进度，或读取TXL2Occ来了解FIFO占用水平。

4.2.2 VLAN标签的插入与移���这是TX L2 FIFO一个非常强大的功能，常用于工业网络中的VLAN优先级标记。

• 标签插入：通过配置TAG insertion mode（R18[1:0]），可以命令硬件在数据帧的特定位置（通常是以太网类型字段之后）自动插入4字节的802.1Q VLAN标签或6字节的HSR标签。标签内容来自预先配置的VLAN_PORT和SEQ_PORT等寄存器。这完全由硬件完成，不占用PRU计算资源。
• 标签移除：同样，可以配置硬件在发送前检查帧中是否包含特定的VLAN标签（通过比较TX_VLAN_TYPE_TAG寄存器），如果匹配，则自动移除这4个字节。这在实现“VLAN剥离”功能时极其高效。

4.2.3 发送抢占（TX Preemption）这是为了支持IEEE 802.3br（时间敏感网络中的帧抢占）特性。它允许高优先级的“快速帧”中断正在发送的低优先级“可抢占帧”。

• 可抢占帧：在向TX L2 FIFO写入第一个数据之前，设置PRE_FRAME标志。
• 分片与CRC：如果可抢占帧被中断，需要在写入最后一个分片数据后、TX L1 FIFO排空前，设置EOF_MCRC_REQ标志，硬件会为该分片生成一个中间CRC（MCRC）。
• 快速帧：快速帧发送时，设置EXP_FRAME标志。
• 帧结束：对于可抢占帧的最后一个分片（或未被抢占的完整帧），在写入最后数据后设置TX_EOF_REQ标志，硬件会生成标准的帧尾CRC。

这个机制使得PRU能够支持更复杂的实时网络调度，而无需软件参与每一比特的发送时序。

4.3 数据混合发送：TX掩码的妙用

当TX_32_MODE_EN = 0（默认）时，R30的高16位被用作TX掩码。此时发送的数据由以下公式决定：发送数据 = (R30数据 & 掩码) | (RX L1 FIFO数据 & ~掩码)

应用场景：实现一个简单的2端口交换机。PRU从Port 0收到一个帧，需要转发到Port 1。同时，PRU可能想修改帧中的某个字段（如TTL）。

1. 将Port 0的MII_RT模块配置为RX L1直通模式。
2. 在Port 1的发送路径中，将TX掩码大部分位设为0x00，表示发送数据来自Port 0的RX L1 FIFO（即转发）。
3. 对于需要修改的特定字节（如TTL字段），在对应的掩码位设置为0xFF，并在R30的对应位置写入新的TTL值。
4. 执行TX_PUSH16，硬件会自动完成数据的混合与发送。

这样，PRU仅用几条指令就完成了一字节的修改和整个帧的转发，效率远高于将整个帧读入PRU内存、修改、再写回。

5. 错误检测、中断与系统集成

5.1 接收错误检测机制

MII_RT模块提供了多层次的错误检测，这些信息对于构建可靠的网络应用至关重要。

5.1.1 实时错误信号

• RX_ERR(MII信号)：由PHY驱动，表示在RXDV有效期间检测到符号错误。
• ERROR_CRC：硬件计算的CRC与帧尾的CRC不匹配。
• ERROR_NIBBLE：帧在奇数个半字节处结束，即帧长不是字节的整数倍，这违反了以太网规范。
• RX_MAX/MIN_FRM_CNT_ERR：帧长超过或低于预设的阈值。

这些错误状态会实时反映在R31或RX L2的状态字节中。需要注意的是，对于RGMII和SGMII模式，RX_ERR信号仅在帧起始定界符（SFD）之后和载荷期间被采样，这与标准MII模式有所不同。

5.1.2 错误事件窗口与中断模块内部有一个运行计数器，在一个10微秒的非重叠窗口内统计接收错误事件。如果10微秒内错误事件达到或超过32次，模块就会向中断控制器（INTC）发出通知。这个机制用于检测持续的、高频率的错误，可能指示链路质量严重下降或受到干扰。这个10微秒窗口在模块复位解除后立即开始计时。

调试技巧：在调试链路不稳定问题时，除了检查上述实时错误位，还应使能RX_ERR计数器的中断，并在中断服务程序中检查错误计数寄存器。这有助于区分是偶发的单个错误还是持续的突发错误，两者的排查方向不同（前者可能是偶发干扰，后者可能是时钟不同步、阻抗不匹配等硬件问题）。

5.2 中断与事件处理

PRU-ICSS的中断系统非常灵活。MII_RT模块可以产生多种系统事件，映射到PRU核心的中断或用于触发其他操作。

• 接收溢出事件：PRU<n>_RX_OVERFLOW。必须及时处理，否则后续帧无法接收。
• 发送欠载事件：PRU<n>_TX_UNDERFLOW。表示TX FIFO为空时TX_EN需要激活，通常是因为firmware未能及时提供数据。
• 错误计数事件：上述的32次/10us错误事件。
• 自定义事件：还可以基于帧状态（如EOF）等条件配置事件。

编程模型建议：对于高实时性要求，通常采用轮询（Polling）主状态寄存器（如R31的DATA_RDY）。对于非实时或低频事件（如溢出、错误计数），可以采用中断。PRU的中断延迟是确定性的，但进入和退出中断服务程序仍有开销。需要根据具体应用权衡。

5.3 与PRU-ICSS其他模块的协同

MII_RT不是孤立的，它与PRU-ICSS内的其他模块紧密协作。

• PRU核心：通过R30、R31、XFR指令和寄存器文件进行直接、高速的数据与控制交互。
• 中断控制器（INTC）：接收并管理来自MII_RT的各种错误和状态事件。
• 工业以太网外设：对于支持PROFINET IRT、EtherCAT等协议的型号，MII_RT的数据路径会与这些协议加速硬件连接，实现更精确的时间戳和调度。

在系统设计时，需要通盘考虑。例如，如果使用了RX L2缓冲区并启用了背压，就需要评估这对上游数据源（如另一个PRU或DMA）可能产生的影响。再比如，TX L2的标签插入功能需要与PRU-ICSS内存储标签内容的配置寄存器正确配合。

6. 性能优化与常见问题排查

6.1 性能优化要点

1. 路径选择：

   • 追求最低延迟（< 1us）：使用RX L1直通模式，并确保PRU中断或轮询的响应时间极短。处理逻辑必须极其精简。
   • 追求高吞吐量或复杂处理：使用RX L2缓冲区模式。利用XFR指令的批量传输能力，减少指令开销。合理规划Bank切换逻辑，避免PRU等待数据或硬件覆盖未读数据。

2. 指令优化：

   • 在POP/PUSH操作后，严格遵守硬件延迟要求（如等待2个周期再读状态）。
   • 对RX L2的数据处理，尽量使用PRU的并行操作和位域操作指令，提高处理效率。
   • 避免在关键的数据收发循环中进行耗时的乘除运算或复杂内存访问。

3. 内存与寄存器使用：

   • PRU的本地数据内存（Data RAM）很小，应优先用于存储状态机和协议上下文，而非大量数据。大数据应通过XFR指令快速处理或借助共享内存与主CPU交换。
   • 合理使用PRU的30个通用寄存器（R0-R29），减少对数据内存的访问。

6.2 常见问题与排查实录

问题1：数据接收不全，频繁发生RX FIFO溢出。

• 可能原因：PRU firmware处理速度慢于数据到达速率。
• 排查步骤：
  1. 检查是否使能了RX L2缓冲区。如果没有，对于大数据包，强烈建议启用。
  2. 在firmware中，在读取数据的关键循环内插入一个计数器，估算处理每个字节或每个帧所需的时钟周期数。与MII接口的数据速率（如100Mbps下，每秒12.5M字节）进行对比。
  3. 优化处理逻辑：能否简化？能否将部分工作（如统计）推迟到帧接收完成后进行？
  4. 检查是否正确地、及时地执行了POP操作。延迟的POP会导致FIFO堆积。

问题2：发送的帧CRC错误，对端无法识别。

• 可能原因A：TX_EOF标志设置时机不对。
  • 排查：确保在帧的最后一个数据字节被推送到TX FIFO（L1或L2）之后，再设置TX_EOF标志。如果在设置TX_EOF后又���送了数据，这些数据会被当作下一帧的开始，导致当前帧CRC计算错误。
• 可能原因B：使用了TX掩码，但掩码值计算错误，导致发送的数据流混乱。
  • 排查：在调试阶段，可以先将TX掩码全部设置为0xFFFF（全部使用R30数据）或0x0000（全部使用RX数据），发送一个已知的测试帧，看是否正常。然后逐步引入掩码逻辑。

问题3：启用RX L2后，偶尔会丢失一帧数据。

• 可能原因：PRU未能在硬件覆写Bank之前读取数据。
  • 排查：
    1. 确保软件正确维护了读指针和Bank切换逻辑。
    2. 检查对STATUS_RDY和RX_EOF位的判断逻辑是否正确。一个完整的帧可能跨多个Bank，需要在收到RX_EOF标志的Bank才算处理完一帧。
    3. 在读取一个Bank的数据后，是否及时地通过写相应寄存器（如RX_L2_DONE）来确认完成，以便硬件可以复用该Bank？参考具体型号的寄存器手册确认操作流程。

问题4：RGMII/SGMII模式下，错误检测行为与手册描述不符。

• 注意：如手册所述，在RGMII和SGMII模式下，RX_ERR检测逻辑与标准MII不同。它仅在SFD之后和载荷期间有效。如果在 preamble 期间遇到错误，可能无法通过RX_ERR位检测到。
  • 应对：在这些模式下，应更依赖ERROR_CRC和帧长度错误等基于接收内容的检查，而非仅依赖RX_ERR信号。

问题5：调试时如何观察内部数据流？

• 方法：充分利用PRU的调试功能。可以通过Code Composer Studio等IDE连接PRU，设置断点，实时查看R30、R31、R2-R13等寄存器的值。对于FIFO状态，可以读取MII_RT_RX_FIFO_LEVEL和MII_RT_TX_FIFO_LEVEL等寄存器（如果可用）。最直接的方法是在关键点将状态和数据通过共享内存或GPIO输出，供主CPU分析。