[参考译文] TM4C1294NCPDT：在 TM4C1294NCPDT 中运行数小时后、以太网通信失败(从先前的线程继续)

您好、Krishna、

 不幸的是、我真的不知道导致它在30小时后失败的原因。 在您尝试调查的最后一个主题中、更改不同的开关是否会产生影响？ 您能否提供一些更新？

 我有一些问题和建议。

 －更换开关是否会产生影响？

 -您的所有电路板是否都有相同的问题？ 如果是这种情况、那么我将重点介绍软件方面。

 您说您的应用程序基于 tcpecho 示例。 如果您按原样运行 tcpecho 示例、您将在运行自己的应用程序时看到的运行小时数之后看到任何故障。

 在这里、我只是想了解 TivaWare tcpecho 示例是否可能是一个问题、因为您说过您参考它来开发您的应用。 您能参考 https://github.com/dreamcat4/lwip/blob/master/contrib/apps/tcpecho_raw/echo.c 上的另一个 tcpecho 示例。这是库存 lwIP tcpecho 示例。 看起来更复杂、但可以正常工作。 只需从该文件调用 ECHO_init()即可。 如果您的应用基于该回波示例、它是否会产生影响？ 我只是想知道这是软件问题还是其他问题需要考虑。 我正在尝试的是一个消除过程、以缩小原因范围。  

您好、Charles、

我尝试了不同 的交换机和电缆，即使一周后，问题也没有出现。 但是、使用这组交换机和电缆时、问题发生了两次。 30小时后，6小时后， 为了消除电缆问题，我单独检查了3根电缆，但没有交换机，他们 每天都在工作，没有任何问题，我强烈怀疑交换机。 为了确认它、我必须返回到另一个开关并再次观察。  

同时、我修改了我的程序(对于 RTC、SD 卡存储、2个与 MSP432的 SPI 通信以及 Beagle Bone Black 等和 NOSYS 来说相当复杂、并且没有以太网中断。 以太网在主超级循环中进行处理)、以便它在连接的 LaunchPad 上工作(无需其他硬件)、并自昨天起保持运行。  我将进行几天的观察、并告诉您。 如果问题出现在此处、当我使用 TeraTerm 记录 UART 输出时、查找根本原因可能会更容易一些。

我将尝试在 LaunchPad 上运行一个更简单的程序的另一个建议。

我也会尝试这种方法。

 感谢您的建议。

您好！

请仔细阅读 David Wilson 在这篇文章  https://e2e.ti.com/support/microcontrollers/other/f/908/t/319674?Optimizing-UDP-in-lwIP-on-TIVA-how-to-determine-when-a-packet-has-been-sent-中的回复。  基本上、您不应从以太网中断处理程序以外的上下文调用 LwIP (如 tcp_send)、因为 LwIP 不可重入、因此您只能从一个上下文调用。  

更新：

37小时后、在 Launchpad 上运行的程序也停止了在 TCP 上进行通信。 我以20分钟的固定间隔记录了状态、发现在挂起 EMACIntStatus 时变为零。 我已重置 LaunchPad、以便在 接下来的许多小时内再次观察。 稍后、我将更换开关并重试并报告。  

固件检测到挂起后、它将等待 30秒、并 使用 旧值调用 lwIPNetworkConfigChange、以尝试重新启动。 但这没有影响。

但是、如果我们对 MCU 执行软件复位、它将恢复。 但是、 由于我们在复位期间丢失了一些数据、因此这不是一个可取的解决方法。

我是否必须记录其他参数才能深入了解问题？  

您好、Charles、

我认为我做的这个部分是正确的。 我将再次交叉检查。 我们的要求是、计时器中断(10ms)用于数据采集、而数据采集不会被任何其他任务(甚至以太网任务)中断。 因此、我们很难看到以太网功能是在没有硬件以太网中断的情况下实现的。  

我 将 制作一个简明文件、展示为实现这一点所做的修改。  

实际上、我在 这篇文章的中午12点博客上看到了这封信  

high12noon.neocities.org/lwip_polled_tm4c129.html

BTW 使用 Launch Pad 的第二次测试在10小时后失败。

现在，我们已将 可疑开关(D-Link D1008D)替换为另一个开关(D-Link DES1008C)。 我们将在几天内进行观察并报告。

谢谢你。

好的、现在让我们看看使用不同开关的结果。