[参考译文] CCS/TM4C1294NCPDT：EMAC 在运行数月后进入不良状态

我不知道会导致这种情况的任何已知问题。

您能描述一下您的网络拓扑吗？

您是否能够调试这些原型板？  即、它们是否仍然连接到 JTAG 和 CCS？ 如果是、这将极大地帮助您了解可能发生的情况。

[引用 user="Steve Packwood"]因为他们仍然会接收数据，我可以发送重新启动命令，他们都返回100%工作状态。[/引用]

如果没有 JTAG、您是否可以在设备上运行 Telnet 服务器？ (实际上、这在任何情况下都很有用)。 如果是，您是否能够通过 Telnet 登录？ 这里有一些有用的东西、比如我们可以检查的 UDP 统计数据。

[引用 user="Steve Packwood">运行一个简单的应用程序、通过 UDP 端口发送/接收数据、并在不同的多播端口上发送数据。 [/报价]

流量有多大？

您的系统中还有其他什么情况？ 是否有大量任务线程、而且它会做大量的工作？ 或不是太多、轻载的东西。 还是介于两者之间？

[报价用户="Steve Packwood"]他们无法 ping 通，但仍在连接到的设备上的 ARP 表中，如果我使用 arp -d.清除了条目，他们将继续重新添加。

这意味着 ARP 数据包从设备发出、因此它能够发送一些数据。

发生这种情况时、您是否能够获得 Wireshark 捕获？ 您是否看到任何 ICMP 错误数据包？ 您能在线上看到 ping 回复吗？ (这可能表示它们确实是从 Tiva 板出来的、但不会将其返回到发送 ping 的 PC。 也许他们之间有一个路由器会使他们跌落、例如、只是一个猜测。

[引用 USER="Steve Packwood]Tiva 器件上的 UDP 端口仍在接收来自我的主机的数据、但并未向外发送响应。 [...] 多播 UDP 端口仍在成功发送。[/quot]

好的、我只是想确保我清楚地知道发生了什么。 您的电路板不再能够发送 UDP 数据或 ping 应答。

它们仍在向外发送 MCAST 数据、并且能够 RX UDP 数据和(您认为) RX ping。

Steve

[引述 user="Steven Connell"]您能在线上看到 ping 回复吗？ (这可能表示它们确实是从 Tiva 板出来的、但不会将其返回到发送 ping 的 PC。 也许他们之间有一个路由器会将他们丢弃、例如、只是一个猜测。

然而-正如海报的主题栏所说的、"工作数月！"   这是否能消除(任何)路由器问题？   (我们必须假定，在成功数月后，多台路由器并不会全部失败。   正如系统运行数月一样、路由器似乎"没有责任！"

所有其他诊断建议似乎都经过深思熟虑、但上述"逻辑"超出了我(以及其他少数人)的理解范围...

我同意、仅仅因为它"工作数月"并不意味着它不能成为路由器问题。   但是、在器件的下电上电后、它开始正常工作的事实将是如此

似乎表明问题与路由器无关。   

[引用用户="Steve Packwood"]

我同意、仅仅因为它"工作数月"并不意味着它不能成为路由器问题。   但是、在器件的下电上电后、它开始正常工作的事实将是如此

似乎表明问题与路由器无关。   

[/报价]

不一定。 重新启动设备可能会强制路由器清除以前的条目。 此外、重新启动设备也可能会重新启动路由器(例如、如果它们位于同一电源线上、则通过重启电源重新启动)。

现在、如果仅重新启动路由器并不能改善问题、我会更加关注器件。

Robert

[引述 USER="CB1_MOBILE "]然而-正如海报的主题行所述，“工作数月！”   这是否能消除(任何)路由器问题？   (我们必须假定，在成功数月后，多台路由器并不会全部失败。 [/报价]

不、我看不出你怎么能得出这个结论。 您如何从逻辑上做出这一假设？

我们似乎正在研究一个包含许多组件的系统、其中任何组件都可能在任何给定时间导致问题。 这种系统运行数月并不意味着一旦出现问题、您就可以自动消除某些变量。

您至少不能基于到目前为止提供的信息。  您在上面提到了多台路由器、但没有人说过存在多台路由器。 实际上，没有人针对任何路由器的存在发表过任何意见。  正如我最初所说的那样，*也许*有一个路由器，因为这也是我对系统拓扑结构的查询的一部分(我仍然不清楚这一点)。

或者、您可能比此主题中所说的更了解此问题？

Steve、

我仍然不确定您的网络拓扑是什么。 您能在这里提供一些见解吗？

[引用用户="Steve Packwood"]我检查了内存使用情况，似乎没有任何内存泄漏或可能溢出的任务[/引用]

我很好奇、您是如何在没有 JTAG 的情况下检查这一点的？ 您必须有其他方法来从电路板上获得一些诊断(？)

[引用 user="Steve Packwood"]我用来验证这一点的另一种方法是查看开关计数器并发现它们不会递增

您能否提供有关此方面的更多详细信息？

谢谢、

Steve

[引用用户="Robert Adsett72"]

不一定。 重新启动设备可能会强制路由器清除以前的条目。 此外、重新启动设备也可能会重新启动路由器(例如、如果它们位于同一电源线上、则通过重启电源重新启动)。

现在、如果仅重新启动路由器并不能改善问题、我会更加关注器件。

[/报价]

好的地方。 NDK 的路由表也可能存在问题(例如、表中的数据损坏、导致 TX 数据包丢失、通过重新引导修复)。

我认为，如果此问题再次出现，重新启动路由器将为我们提供一个良好的数据点(即，如果有路由器：)

Steve

我的朋友-不是"您"介绍了路由器(可能)的存在吗？   我提供您之前撰写的一份副本：

[引用 USER="CB1_MOBILE "]

那么、您可能会提出一些抗议-正确地针对" 路由器"建议的来源？   (你是这样-不是吗？)   而且-虽然您的"路由器引入已"冻结"(通过您的直接报价) 、但我们注意到它已(现在)"退出"此线程。  

还可以 已将4个系统确定为"故障"-因此、假设(每个)可能包含此类"路由器"似乎是"合理的"-这证明我使用 "多个"是合理的。  

   来自供应商代表的令人惊讶(和不受欢迎)的"苛刻"-针对外部人员-试图提供帮助...   

现在已经很清楚了(您)关于 "路由器存在"的建议是正确的-我的意思 是"一旦工作(可能)、就会将其从未来/下游中删除、"可疑列表"的意思是过早的。   (由于路由器可能受到外部条件的影响、因此无法保证"继续工作"。   我的坏！    它(确实)看起来就像存在"多个"路由器-这会对所有(本例中为四个)发生故障的路由器产生"标志"、而其他四个路由器则仍然存在-对"单个路由器"增加了更多的"怀疑"、从而证明了(唯一的)疑似故障...

Steve、

网络在与 Tiva 器件相同的子网上有一个 Windows 框、因此没有路由器。  有一个电池调制解调器

 允许我 将 RDP 至 windows 框并启动对 Tiva 设备的 ping 的网络。   网络上的每个组件(包括交换机)都会 频繁地进行下电上电

这不能解决问题。  只有在 Tiva 器件上循环粉末可以清除该问题。  我无法检查上是否存在内存泄漏

现场单元、但我没有在我的实验单元上看到任何我安装了调试器的泄漏。   在我尝试 ping Tiva 器件时

当处于不良状态时、传出交换机端口数据包计数器(到 Tiva 器件) 会增加、但我看不到传入数据包计数器会增加

表明 Tiva 器件不发送 ping 响应。  我确实看到传入数据包计数器响应 ARP 请求增加。

[引用 user="CB1_MOBILE]/   供应商代表的"不受欢迎的"令人惊讶(和不受欢迎)-针对外部人员-试图提供帮助...  [/报价]

主席先生，也许我们走错了脚。 我只是认为这是专业人士就解决问题的逻辑所进行的辩论。 如果我觉得过于苛刻，我的道歉，这不是我的意图！

谢谢、

Steve

Steve、

您是否在 Windows 包装盒(与 Tiva 板位于同一子网)上安装了 Wireshark？ 如果是、请在该问题再次出现时抓取一些捕获。

1.出现此问题时、您是否看到 Tiva 板发出任何 ARP 请求？ (以 w/s 为单位)

2.电路板上是否有 ICMP 数据包？

3.如果有任何方法可以检查以下全局变量的值，这可能会有所帮助。 我意识到您可能只能在您的测试环境中执行此操作：
   a.新闻通讯社
       －ips.CantForward
       －ips.Localnorroute
       - ips.Localout

   B. UDPS
       －UDPS.RcvNoPort
       - UDPS.SndTotal
       - UDPS.SndNoPacket

   c._ICMPIn[]
    －ICMP 统计数据存储在数组中，而不是上述两个结构

   我们真的想寻找正在增长的*任何*统计数据，因为这些数据可能会为我们提供所有重要线索。

4.我意识到这是在生产环境中发生的，所以不确定这是否可行。 但是、以防万一-这些器件是否连接到任何类型的显示器、以显示您从程序输出的结果？ 或者是否已禁用所有程序跟踪？

   -如果您有跟踪，则可以创建一个新的线程，该线程侦听要打印的命令。 这可能需要在 UDP 套接字上完成、因为电路板无法发送 TX 数据包、因此无法完成 TCP 3路握手。

   您可以打印上面提到的一些统计数据以及路由表(有关如何执行此操作的示例，请参见 telnet 控制台代码[ti/ndk/tools/console/conroute.c、DumpRouteTable()])

   -还想知道您是否看到任何有关正在删除的路由的跟踪语句...

或者、也许这更好、您可以等待 UDP 套接字上的特殊命令、然后在多播套接字上发出 TX 调试信息(因为 TX 在那里工作)。 您可以等待 PC 上的多播数据并在其中显示。

需要注意的一点是、多播会跳过所有路由查找、因此这也表示路由问题。

[引用 user="Steve Packwood"]我遇到的问题是什么原因会导致这种情况，以及为什么来自主机器件的新 ARP 请求不能修复它？

这一点很难说。 内存不足问题，例如从 PC 接收到 ARP 时无法为 PC 添加 ARP 条目。 或者、内存被占用可能是原因。 在这种情况下查看路由表将会很有帮助(下面将详细介绍)。 要解决该问题、具体取决于根本原因。 很抱歉,太含糊了……

Steve

感谢您的回应-您之前的书面内容在这里有几处表现为"临界性/攻击性"。    未寻求/未寻求道歉、但针对试图提供帮助的外部人员确实很好奇...  (您的最后一句话显然"太过分了"-先前的陈述在逻辑上为您的技术辩护。 立场-最后一个立场似乎是针对(仅)犯罪。)     (参加过加州大学洛杉矶分校工程师与法学院的课程-我认为这种评估是正确的- 他人也同样认为-并且显然未能反映恰当的"正常/习惯"论坛互动。)

在这个主题中、您似乎非常"符合技术要求"-也许更好地"理解"他人的观点"(即使是不同的观点/如果不同)值得考虑...

[引用 user="CB1_MOBIST"]最后一个似乎针对(仅)犯罪。[/引用]

我认为您是指以下内容(如果我错了、请纠正我)？

如果是、我认为可能会有一个简单的沟通错误。

"或者、您可能比在本主题中所说的更了解此问题？"

这里根本没有任何犯罪行为。 当我在该主题中阅读您的原始帖子时、我实际上印象中您对此问题的信息比该主题中提供的信息更多。 我认为您可能是 Steve (Packwood)的同事、因此对网络拓扑有一些深刻的了解、无法根据线程本身提供的信息进行辨别。

再说一次、我认为这是一个沟通错误的案例。

谢谢、

Steve

句子是"...也许您了解更多..." 我本人/其他几个人认为这是一种侵略性的行为-但现在接受您的免责声明。

至于"沟通不当"-这种"最佳判断"可能是因为对你最近的"其他"职位与对我的"其他"职位的抽样比较？   语调有明显的不同----这种语调反对"沟通不当"----不是吗？

我希望您的专业知识可以帮助此海报解决这一令人不安的问题。    我现在是“和平”的。