[参考译文] TMS320F28388D：以太网问题- TX 丢失中断和 TX 数据包传输延迟

您好、Jay、

专家在度假,他们应该能够很快回到你。

此致、

阿米尔·奥马尔

感谢您的更新！

您好！  

抱歉、没有以太网的轮询模式示例。  

您在看到去透传输数据包之前是否在 Wireshark 中看到任何其他消息？

此致

西达尔特

没有什么特别的。 我使用 ping 流量和一些导致延迟的 UDP (特定于应用)数据包访问它。 它们似乎在驱动程序/硬件层中卡住/延迟。 我看到了 TX 中断、但没有看到线路上的数据包。 哪些信息可以帮助解决问题？ 驱动器中是否有有用的计数器？

如果我要在一个简单的投票模式下使用驱动程序、我有没有想过如何实现它？ 正如另一个用户编写的、我将中断例程放在了轮询循环中并禁用了中断。 它的作用是：

void pollenet (void)

{

Ethernet_receiveISR()；
以太网传输 ISR()；

｝

原始帖子有更多信息。 谢谢。

您好！  

driverlib 中有计数器变量可以帮助缩小问题范围- Ethernet_txInterruptCount 和 Ethernet_numTxPktFreeCallback

对于这些预定义符号"ethernet_debug"必须添加到工程中。

如前所述、尚未尝试驱动器的轮询模式、因此没有任何输入。

此致

西达尔特  

我通常使用的驱动程序与回调,但尝试其他控制方法。 我也会看到与 ISR/回调相关的问题。

我一直在看那些计数器。 TX ISR 会触发但延迟、或者完全不触发。  

我将收集更多的数据来展示问题所在。 我的上一篇文章(此处第一篇文章中的链接)显示了缺失的 TX ISR/回调的数据。

谢谢。

当触发 TX ISR 时、这是否是数据包已发送的良好指示？ 是否有硬件缓冲区可以在中断时间之后保存 TX 消息？  

下面是我看到的一个例子：

数据包1246由主机作为 Ping 的一部分发送。

1247实际上是前一个 ARP 响应、来自三个 ARP 请求、而不在屏幕截图中。 (其他为1249和1252)

1248是第一个 ping。 最终达到1254。

接下来的 ping 是1,250,1251和1253、所有这些都有延迟响应。

代码在 RX 中断上运行、处理数据包并发送 TX 响应。 没有延迟、尤其是~60s。

当 TX 中断命中时、TX 数据包资源将被释放。

另一个示例：

数据包171/172是正常(尽管响应缓慢) ping。

第183号包裹被严重延误。  

最后三个 ARP 是在后台发送其他一些随机流量后接收到的。 不确定它们被缓冲在了什么位置。

看起来某些 RX 数据包位于缓冲区中、并没有触发 RX ISR、或者没有被完全清空。 驱动程序如何处理队列中的多个数据包？ 它是否依赖于 ISR？ 如果我正在响应 RX ISR 并且收到另一个数据包、该怎么办？ 是否应在退出 RX ISR 之前手动检查接收队列？

我得到了大量的 ARP，这似乎导致了 RX 中的延迟--比如输入缓冲器并没有完全耗尽。

当我得到这种 ARP 突发时、我只得到4个中断(而不是8个)、并且只处理前4个数据包。 我可以在 RX 缓冲区中看到数据、但没有收到通知(甚至能够在直接调用 RX ISR 时进行处理)。

由于我也在 ISR 上进行轮询、Ethernet _xxInterruptCount 值被关闭、但 GetPacketBufferCallback 是正确的(初始的16个缓冲器+ 4个处理)。

丢失的数据包似乎未处理。 描述符被分配给应用程序、但在中断中未被处理。

前16个描述符为 TX、后16个为 RX。 除突出显示的那些外、所有都属于 DMA。 数据缓冲区与我预期的数据包匹配。

驱动器是如何设计的？ 技术手册规定"轮询描述符、读取主机所拥有的描述符的状态(发送或接收)"。 在本例中、我可以检查自有位的下一个描述符(正如 Ethernet_device_struct.dmaObj 所指出的那样)、从而确定我需要处理一个数据包。 有什么建议？

谢谢。

是的、TX 中断是一个"发送完成中断"、所以它表示发送数据包已被发送。

我不知道中断为什么没有被触发。  您发送 Ping 请求的频率如何？  

此致

西达尔特

我猜是、它在先前 ISR 的处理过程中被重新触发并被清除。 ping 没有执行此操作... 是一个 ARP。 Wireshark 跟踪显示，请求数据包的间距低至28us。 对前四个进行处理、然后接收其余四个并坐在描述符队列中。 它们仅在另一个数据包到达时开始被处理并再次触发 RX 中断。 这是我的 RX Ping 延迟的来源... Ping 数据包会一直处于描述符队列中、直到处理完前一个 ARP 数据包。

因此、当有描述符需要处理时、RX 中断似乎不会被重新触发/启用。 应如何处理这一点？ 根据技术手册进行轮询？ 对于这种情况、驱动程序中似乎没有一种方法。 这是完全意外的行为吗？ 为了防止这种情况、流程中应该有哪些不同？

我切换到轮询方式、发现 ARP 突发暂停了 RX DMA。 从驱动程序和手册中、取消暂停的过程是：

* 1. 将当前 RX 描述符的所有权更改为 DMA
*
* 2. 发出接收轮询请求命令
*
* 3. 发出对描述符尾指针寄存器的写入操作

什么是轮询请求命令？ 手册和驱动程序都提到了它、但驱动程序不执行任何操作：

        /* To un-suspend the DMA:
         *
         * 1. Change ownership of current RX descriptor to DMA
         *
         * 2. Issue a receive poll demand command
         *
         * 3. Issue a write to the descriptor tail pointer register
         */

        /* 1. Change current descriptor owernship back to DMA */
        descPtr = (Ethernet_HW_descriptor *)(HWREG(
                Ethernet_device_struct.baseAddresses.enet_base +
                (uint32_t)ETHERNET_O_DMA_CH0_CURRENT_APP_RXDESC));

        descPtr->des3 = ETHERNET_DESC_OWNER | ETHERNET_RX_DESC_IOC |
                        ETHERNET_RX_DESC_BUF1_VALID;

        /* 2. Issue a receive poll demand command */

        /* 3. Issue a write to the descriptor tail pointer register */
        tailPtr = (Ethernet_HW_descriptor *)(HWREG(
                Ethernet_device_struct.baseAddresses.enet_base +
                (uint32_t)ETHERNET_O_DMA_CH0_RXDESC_TAIL_POINTER));

        Ethernet_writeRxDescTailPointer(
            Ethernet_device_struct.baseAddresses.enet_base,
            ETHERNET_DMA_CHANNEL_NUM_0,
            tailPtr);

另外、我曾尝试使用 ARP 卸载来加速处理过程。 我的理解是、ARP 卸载将自动处理 ARP 请求、而无需将描述符传递给固件/应用程序。 是这样吗？ 我已经启用了 MAC 配置寄存器中的 ARPEN 位：

  EtherNet_setMACConfiguration (EMAC_BASE、ETHERNET_MAC_CONFIGURATION_ARPEN)；

但它似乎并不像我想的那样起作用。 此位的说明指出"仅当启用 IPv4 ARP 卸载时、此位才可用
"、我认为这就是其中之一。 这是一个拼写错误吗？ 是否有其他字段需要设置(除 IP 地址以外)。

谢谢。

您好！  

接收轮询请求不过是更新尾指针寄存器、而驱动程序已经在执行此操作。  

您是否可以检查 DMA_CH0_Status 寄存器的'RBU'位 以查看接收器缓冲区是否不可用？  

在执行 ARP 卸载时、您是否在 MAC_ARP_Address 寄存器中配置了 IP 地址？   是否 设置了 MAC_HW_Feature0寄存器中的 ARPOFFSEL 位？  这应该表明是否启用了 ARP 卸载。  同意"启用 IPv4 ARP 卸载"文本令人困惑、因为它应引用此位本身。

此致

西达尔特

是的、我检查了一下、发现 ARP 风暴耗尽了我的指针。 这就是我询问 ARP Offload 以帮助解决此问题的原因。 您说第2步与第3步相同吗？ 这与我观察到的 DMA 引擎行为相匹配。 它会清除缓冲区不可用问题并继续处理数据包。 在轮询循环中、我只检查该位、如果设置了它、则运行清除过程。

对于 ARP Offload、我将调用这两个驱动程序 API：

EtherNet_setMACConfiguration (EMAC_BASE、ETHERNET_MAC_CONFIGURATION_ARPEN)；   

我还将设置 IP、并给驱动程序添加一个呼叫。

MAC_HW_Feature0 (偏移量0x11C) = 0x0E1D73F5、其中设置了 ARPOFFSEL 位9。 有趣的是、默认情况下、它是根据文档设置的。

我想这是您要询问的两个字段。 我仍然看到数据包正在传递到应用程序。 这种行为到底应该是什么样子让人感到有些不清楚。 是否自动处理_all_ARP 数据包？ 或 ARP 数据包不是针对我们的 IP 过滤、而匹配数据包会发送到应用程序？

我还缺少什么？ 谢谢

您好！  

我认为不会自动处理所有 ARP 数据包。  只有与  配置的 IP 地址匹配的 onee 才由硬件处理、不会发送到应用程序/驱动程序。  另外、它一次只处理一个 ARP 请求。 如果它在处理较早的 ARP 请求时收到 ARP 请求，它会 将新的 ARP 请求数据包转发给应用程序。

此致

西达尔特

好的、我会检查一下是否是这样。 在我上面发布的示例中、它不会处理任何这些数据包、因此应该会转发到应用程序层。

您能否在 MAC_ARP_Address 寄存器中确认字节顺序？ 文档有点模糊。 在本例中、所需的 IP 为172.16.201.201 (0xAC10C9C9)。  

我刚刚确认 ARP 数据包仍被转发到应用程序层以获得所需的 IP。

谢谢。

您好！  

IP 地址应采用 主机字节顺序格式、  

请参阅此帖子

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1082860/tms320f28388d-mac_arp_address-bytes-order

此致

西达尔特

BTW、总结原始 TT 中列出的问题：

- TX 中断没有被错过,但是一个线程错误在一个队列外部的模块

-轮询 RX 解决了我的大部分处理问题和处理延迟,因为我直接检查了用户的描述符位,从不错过了 RX 中断。 用户可以使用 RX 中断、但是应该定期检查用户位。