工具/软件：TI-RTOS
由于 RTOS/TM4C129XNCZAD：是否有办法复位以太网 PHY 和 NDK？ 其中描述了以太网通信的间歇性故障、 通过使用修改的 tcpEcho_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT 示例创建了针对 TivaC 2.16.1.14的 TI-RTOS 以太网应力测试、并进行了更改以允许增加数据速率。 当使用 四个数据大小 为4380且零延迟的关闭 tcpSendReceive 程序时、Tiva 以太网正在发送和接收大约23 Mbit/s 的数据、但在几秒到几十分钟后、由于 Tiva 无法发送以太网数据包、测试停止。 在 CCS Expressions 视图中查看'EMACSnow.c'：：EMACSnow_Private EMAC 驱动程序统计信息显示仍可以接收以太网数据包(rxCount 和 isrCount 增量)、但无法传输以太网数据包(txSent 不变、txDroipped 增量)。
TI-RTOS 中的 EMACSnow.c 驱动程序通过以下方式处理中断：
a) EMACSnow_hwiIntFxn()调用 EMACIntStatus()来读取中断状态，然后 调用 EMACIntClear ()来清除中断状态。
b) EMACSnow_hwiIntFxn()禁用中断。
c) EMACSnow_hwiIntFxn()将中断状态存储在全局变量 g_ulStatus 中。
d) EMACSnow_hwiIntFxn()调用 Swi_post ()以使 Swi 处理传入的数据包。
e) EMACSnow_handlePackets ()是 Swi 处理程序读取 g_ulStatus 以确定是否处理发送和/或接收中断。
f) EMACSnow_handlePackets ()重新启用中断。
通过调查测试失败的原因，发现在 运行 EMACSnow_hwiIntFxn()之前，可以调用两次 EMACSnow_handlePackets ()，这可能导致失败。 例如、顺序：
1) 1)所有四个发送描述符都在使用中。
2) 2) EMACSnow_hwiIntFxn ()被调用并将 g_ulStatus 设置为0x10041、这意味着发送和接收中断正暂挂。
3) 3) EMACSnow_hwiIntFxn ()被再次调用、并且没有挂起的中断导致 g_ulStatus 被设置为零。
4) EMACSnow_handlePackets ()运行，但由于 g_ulStatus 为零，因此 EMACSnow_handlePackets ()认为不需要处理发送或接收中断。
5) 5)发送描述符已经完成了传输、并且 EMAC 外设不会再产生任何发送中断。
6) 6)由于2)中的挂起发送中断已丢失 、因此未调用 EMACSnow_processTransente()。
7) 7) Tiva NDK 被卡住、认为所有发送描述符都在等待传输完成、从而导致所有进一步的尝试将 pbuf 排队以使传输失败、 而 EMACSnow_Private．txDropted 递增。
g_ulStatus 上的数据变量跟踪中的以下捕捉 显示了发生传输中断丢失的问题：
在正常使用中、对于每个被处理的中断、 应该有一个来自 EMACSnow_hwiIntFxn ()的对 g_ulStatus 的写入和两个来自 EMACSnow_handlePackets 的对 g_ulStatus 的读取(第一个针对发送中断的读取测试和第二个针对接收中断的读取测试)。 在 EMACSnow_hwiIntFxn()之前，在 EMACSnow_handlePackets ()处理中断之前，上面的线迹中突出显示的行是 EMACSnow_hwiIntFxn()改写之前的值，表示发送和接收中断正等待零。
随附了修改后的 TCP 回显示例，该示例显示了故障，自述文件介绍了所做的更改并对故障 mode.e2e.ti.com/.../7080.tcpEcho_5F00_EK_5F00_TM4C1294XL_5F00_TI_5F00_TivaTM4C1294NCPDT.zip 进行了调查
