您好、Charles、

>>>因此，如果没有 SPI-DMA 任务，程序将始终正常运行。 这是正确的理解吗？  

-是的。 您的理解是正确的。

>>> BIOS 是在管理 SPI-DMA 中断还是将 BIOS 管理的中断与非 BIOS 管理的中断混合在一起？

－ BIOS 管理的和非 BIOS 管理的中断意味着什么？  

我习惯通过.cfg 文件配置 ISR、如下所示。

此致

巴拉

[引用用户="Balasubramani C"]

现在、我们已经在控制台中观察到以下错误消息、之后甚至 ping 命令也没有响应。

00035.600 TcpTimeoutRexmt：重新发送超时

您能否在 CCS 表达式视图中添加以下内容：

'EMACSnow.c'：：EMACSnow_Private 

然后展开结构并选择"Continuous Refresh"选项、并在尝试 ping 命令时观察以下计数的任何变化：

uint32_t rxCount；
uint32_t rxDroipped；
uint32_t txSent；
uint32_t 已压降；
uint32_t 异常；
uint32_t isrCount； 

这将指示 NDK 是否在故障发生后尝试接收或发送任何以太网数据包。

切斯特、您好！

您的建议。 我已检查了使用 CCS 表达式。 但我无法找到问题。 在死区期间、变量没有变化。

系统未响应时、请参阅快照。

此致

巴拉

[引用 user="Balasubramani C"]我已使用 CCS 表达式进行了检查。 但我无法找到问题。 在死区期间、变量没有变化。由于没有报告丢包或异常中断、因此屏幕截图中的内容无法说明问题的原因。

您能否尝试在发生故障之前在 CCS Expressions 视图中启用"Continuous Refresh"选项(在下面的示例中以红色突出显示)、并观察更新(以黄色突出显示)、并确定失败前哪些值发生更改？

您好！

很抱歉耽误你的回答。 这一次、我已经提出了一些可能有助于解决此问题的更多数据。

连接到我的测试设备的 PC 存在问题。 当我连接到安装了 Windows 10操作系统的 PC 时，我没有看到此问题“TcpTimeoutRexmt：重新发送超时”，因为我可以在安装了 Windows 7操作系统的 PC 上看到此超时错误。

我要附加网络高级设置时附带默认参数。 尤其是流量控制启用/禁用。

窗口7操作系统设置

窗口10操作系统设置

如果我尝试更改 Windows 10 PC 中禁用的流控、那么我会得到传输超时错误、但与 Windows 7 PC 相比、此错误的频率最小。

在这两个操作系统中还有一些其他参数、如传输缓冲器和接收缓冲器。

因此、我怀疑我缺少一些需要调整以支持标准网络操作的 NDK 配置吗？

此致

巴拉

您好、Bala、

 如果您在 Windows 7上启用流控制、是否会有所不同？ 我想、启用流量控制后、您的网络适配器将能够向电路板发送暂停帧、以暂停传输、直到缓冲区可用。 我不确定您的 Windows 7计算机中的 NIC 是否为高速 NIC。 这是否是 Windows 7与 Windows 10结果背后的原因？ 您是否从电路板向 PC 发送了大量数据？ 作为实验、如果您降低到 PC 的 Modbus 传输速度、它会产生什么影响？ 请记住、在您的第一篇帖子中、您曾提到一次所有内容都运行良好。 您是否可能更改了导致重新传输的数据吞吐量？

 请查看 此处的这篇文章 、这可能会有所帮助。 尽管这篇文章涉及 Sitara 处理器上使用的 NDK、但它讨论了如何更改两个定义以下、结果是积极的。

#define TCPTV_RTXMIN       10 (   /*最小值重新发送计时器*/

(旧值：2)

#define TCPTV_MINIMALMAXRTT  10   //最大允许 RTT 默认值(0.1秒)*/

(旧值：2)

您好、Charles、

>>>如果您在 Windows 7上启用流控制，是否会有所不同？  

不可以。如果我同时禁用，我将在窗口7 PC 中得到相同的错误。

>>> 我不确定 Windows 7计算机中的 NIC 是否为高速 NIC。 这是否是 Windows 7与 Windows 10结果背后的原因？

－两个 NIC 卡均来自同一个供应商。 这里唯一的区别是 Windows 操作系统。

>>> 您是否从电路板向 PC 发送了大量数据？ 作为实验、如果您降低到 PC 的 Modbus 传输速度、它会产生什么影响？  

-我们在两台 PC 上使用相同的应用程序来生成 Modbus 数据包。 通常情况下、应用的设计方式是 PC 将发送 Modbus 数据包并等待 DUT 的响应、然后再发送另一个数据包。 因此、如果没有 DUT PC 的响应、就不会启动另一个数据包。

请参阅 Wireshark 捕获以了解良好和不良行为。

>>请记住，在您的第一篇帖子中，您曾提到一次所有内容都运行良好。 您是否可能更改了导致重新传输的数据吞吐量？

这是因为不同的问题。 即配置外部 PHY 时出现一些时序问题。 从开发开始、我们就使用 Window 10 PC 进行测试。 我们最近切换到 Windows 7 PC 并找到问题。

>>>请查看 此帖子 ，该帖子可能会有所帮助。 尽管这篇文章涉及 Sitara 处理器上使用的 NDK、但它讨论了如何更改两个定义以下、结果是积极的。

我可以在上述论坛主题中看到另外两个链接，我将无法看到其中一个链接，而且我也无法找到此处提到的参数。

报

巴拉

忘了添加 wirshark 捕获。 立即连接。

很好

第一个故障

此致

巴拉

在两个 Wireshark 转储中、哪个 IP 地址是 TM4C、哪个是 Windows 包装盒？

巴拉

我不熟悉此主题、因此我尝试了解根本问题。 在我看来、添加模拟输入处理任务以及 SPI-DMA 驱动程序支持似乎是导致网络故障的原因。 你同意吗？

Gillon 最近发现的 EMAC Snow 驱动程序中存在一个问题 、并在名为 TI-RTOS for TivaC 2.16.1.14中的 NDK 的论坛主题中报告该问题可能会进入无法传输数据包的状态。 我认为您观察到的问题可能与此相关、因为 SPI-DMA 中断处理可能会影响 NDK 为其中断提供服务的能力。 请查看该主题。 请告诉我您的想法。

~Ramsey

您好 Ramsey、

>>>我不熟悉此主题，因此我想了解根本问题。 在我看来、添加模拟输入处理任务以及 SPI-DMA 驱动程序支持似乎是导致网络故障的原因。 你同意吗？

－不 最初我们认为这可能是问题所在。 在我们删除模拟输入处理任务后、问题仍然存在。

按照论坛中的建议、我将尝试对 EMACSnow.c 文件进行更改、并告知您该行为。

此致

巴拉

e2e.ti.com/.../tcp_5F00_EMACSnow.cHelloRamsey、

我已尝试按照主题中的建议更改 EMACSnow.c 文件中的以下更改  、但问题仍然存在。 我收到相同的错误"00006.500 TcpTimeoutRexmt：Retransmit Timeout"

a)删除 g_ulStatus 全局变量。

b)使 EMACSnow_handlePackets ()调用 Swi_getTrigger ()来获得挂起的中断、而不是读取全局变量。

c)使 EMACSnow_hwiIntFxn ()调用 Swi_or ()来设置传递给 Swi 的挂起中断。

d)也可以删除 EMACSnow_hwiIntFxn()中的中断禁用和 EMACSnow_handlePackets ()中的中断重新启用。 这是因为使用 Swi 触发可防止挂起的中断丢失。

附加了修改后的 EMACSnow.c 文件。

您能检查 EMACSnow.c 文件吗？如果我错过了该文件、请告诉我任何信息吗？

此致

巴拉

您好、Balasubramani C、

因此、在 POR 之前插入以太网电缆时、任何一个 Windows 版本都不会出现超时重新 TXD、这是正确的吗？ 无论如何、这是我通过该线程读取数据时得到的结果。

当以太网电缆在 POR 首次位于 Tiva129.HAL 内时插入/拔下或稍后插入时、LWIP1.4.1出现类似问题。 相对于 (lwiplib.c)读取链路状态寄存 器时未使用布尔标志在 IP 堆栈层中进一步更改链路状态。 这会导致 PCV_POOL 中 PCB 损坏的火车残骸。

不知道 NDK 堆栈 、但在 POR 之后插入以太网电缆时、似乎会发生这种情况。

[引用 user="Balasubramani C">以下是工作行为。
－当设备通电时连接以太网电缆时，之后可以动态更改链路。
非工作行为
－设备未使用以太网电缆连接，并且尝试连接它的运行时间。 在设备中没有预期行为且无法建立以太网连接后连接时

那么、这一切是什么、"运行时间"对我们意味着什么？

您好 BP101：

很抱歉未提供正确的信息。 在调试过程中、我发现以太网交换机配置不正确、无法处理链路状态变化的中断服务例程。 现在、链路问题已经解决、并且在 POR 前后连接的以太网电缆这两种情况下都可以正常工作。 很抱歉在论坛中没有通知您。

现在、我只有一个问题是"TcpTimeoutRexmt：retransmit Timeout -Error"、当我将 DUT 连接到以下 Windows PC 设置时也是如此。

1. Windows 7 PC 同时启用和禁用流控制。

2.窗口10禁用 PC 流控。

此外、当 DUT 与 wondow 10 PC 连接且流控制已启用时、我还没有看到任何"TcpTimeoutRexmt：retransmit Timeout -Error"。  

这是问题的当前摘要。

此致

巴拉

Balasubramani

感谢您试用 EMACSnow 驱动程序修复程序。

您会解释一下测试设置。 DUT 是服务器还是客户端应用程序？ Windows 计算机、客户端或服务器的角色是什么？

测试是否立即失败、或者在失败之前是否有一段正常运行的时间？

您是否会尝试从4月3日开始的 Chester Gillon 文章中描述的实验。 将'EMACSnow.c'：：EMACSnow_Private 放置在表达式窗口中、并在失败前记下要更改的最后一个值。 此外、故障后是否会发生任何变化？

~Ramsey

[引用 user="Balasubramani C"]我发现以太网交换机配置不正确，无法处理链路状态更改的中断服务例程[/quot]

您是否认真， 交换机中有以太网链路状态设置？  因此、应用程序控制链路状态的能力 应该依赖于特定品牌的交换机才能正常工作。   

您证明的似乎是、您的应用程序超过了 DMA 引擎 FIFO 配置的 NDK 配置。 尽管 存在用于处理本地以太网 数据包流的流控制 RFC 、但我们  很少使用它、因为我们已经发现过这种情况。 它要求将 EMAC0配置为类似的流控制 、以 使其正常工作、如 RFC 所述。  您 通过配置 Windows 10流控制所做的一切似乎 都是通过 在数据包帧中插入延迟状态来减慢主机 TX 数据传输到目标 MCU 的速度。  您的客户端实验似乎掩盖了应用程序的问题、即防止 EMAC TX 缓冲区从两个协议或 IP 端口溢出、从而使线路受到冲击。

我们必须提高 TM4C DMA 引擎的 TX 比特率、这样它就不 会因 异常中断或 缓冲器不可用错误而随机卡滞。 可能是 RTOS 内核在 某种程度上控制了数据流速、这是因为它会降低过程中的硬件数据传输速度。 即使 EMAC0未用于传输应用数据、甚至 PHY 仅为 TM4C129x MCU 的外部硬件、也可能保持此状态。

双协议栈需要高速以太网数据 传输、否则 IP 栈中可能会发生列车故障。 低于配置解决   了在利用多个协议(PCB 池)时导致目标 EMAC 中早期 IP 堆栈损坏的不常见数据包溢出问题、在器件链 层3 MLSP 中较高。 通常 、许多 TI 应用会为 TX/RX 传输位速率8及以下配置 EMAC0 DMA 、从而扩大 TX/RX 节流限流器板孔径。

EMAC_BCONFIG_TX_PRIORITY | EMAC_BCONFIG_Mixed_BURST |
EMAC_BCONFIG_DMA_PRIO_权 重2 | EMAC_BCONFIG_PRIORY_2_1、16、16、0)； 

[引用 user="BP101"> 您是否认真，交换机中是否有以太网链路状态设置？  因此、应用程序控制链路状态的能力 应该依赖于特定品牌的交换机才能正常工作。   [/报价]

-以太网交换机具有中断引脚、用于在端口链路状态发生变化时生成中断。 首先、我们将以太网开关中断引脚连接到 处理器的 EN0INTRN 引脚。 这会在系统引导时造成一些问题。 但我仍然不明白它影响处理器启动的确切原因。 我已将 EN0INTRN 配置为 GPIO、并执行单独的任务来轮询链路状态。

[引用 user="BP101"]

双协议栈需要高速以太网数据 传输、否则 IP 栈中可能会发生列车故障。 低于配置解决   了在利用多个协议(PCB 池)时导致目标 EMAC 中早期 IP 堆栈损坏的不常见数据包溢出问题、在器件链 层3 MLSP 中较高。 通常 、许多 TI 应用会为 TX/RX 传输位速率8及以下配置 EMAC0 DMA 、从而扩大 TX/RX 节流限流器板孔径。

EMAC_BCONFIG_TX_PRIORITY | EMAC_BCONFIG_Mixed_BURST |
EMAC_BCONFIG_DMA_PRIO_权 重2 | EMAC_BCONFIG_PRIORY_2_1、16、16、0)； 

[/报价]

-根据您的建议、我已更改上述设置的 EMAC_Config。 但我仍然发现了同样的问题"

TcpTimeoutRexmt：重新发送超时-错误"

此致

巴拉

这只是一个示例、说明了您可能必须如何更改应用程序的一些基本 EMAC0配置才能正常工作、而无需将等待状态添加到数据包中。 也许 EMAC0 DMA 的优先级不是 TX、而是 RX、并且只有从 CCS 调试寄存器视图中、可能会有一个特定的条件与您报告的超时错误相关联。

在 发生超时事件之前、EMACDMARIS REG57或其他寄存器中没有出现异常中断状态、这会让我感到惊讶。 无论如何、如果 NDK 应用正在使用相同的 RFC 流控制握手(lwiplib.c)、您可以启用该握手。

[引用用户="Balasubramani C"]

第一个故障

[/报价]

[引用 user="Balasubramani C"> Windows PC IP 为192.168.1.7和192.168.8.0.7。 其他器件为 TM4C。[/quot]

查看故障情况、从 TM4C 传输的数据包似乎显示了当传输的 Len 为零时 TCP 序列号递增。 例如、数据包编号138、141、144、147。 Wireshark 捕获的屏幕截图是否以某种方式进行了筛选？

您能否为良好和故障情况附加原始 Wireshark 捕获？

您好、Ramsey、

[报价用户="Ramsey "]我希望您能够 发布 EMACSnow_Private 数据并回答我在上述帖子中提出的问题

 给出 Tx 发送超时错误后、查找 EMACSnow_Private 的快照。  

[报价用户="Ramsey "]您是否找到了一个解决方案并继续使用？

不，我仍然没有找到问题的根本原因。

此致

巴拉

切 斯特·吉隆、您好！

[引用用户="Chester Gillon">查看故障情况、从 TM4C 传输的数据包在传输的 Len 为零时显示 TCP 序列号递增。 例如、数据包编号138、141、144、147。 Wireshark 捕获的屏幕截图是否以某种方式进行了筛选？

-是。 它仅针对 TCP 数据包进行了过滤。

[引用 USER="Chester Gillon"]您能否为好的和失败的情况附加原始 Wireshark 捕获？

-

我在这里附加了 Excel 格式的 Wireshark 日志、并附加了 Tx 传输错误数据包的快照。 系统 IP 为192.168.8.2、TM4C1292NCPDT IP 为   192.168.8.4。

e2e.ti.com/.../Modbus_5F00_Tx_5F00_Timeout_5F00_error_5F00_log.xlsx

查看故障案例的快照。

此致

巴拉

您好 、Balasubramani、

感谢您发布 Wireshark 捕获、但我们仍需要有关捕获的更多信息。 首先、我可以在 Excel 文件的第284和285行中看到 NDK 正在响应 ARP 消息、因此看起来 NDK 堆栈仍然有效。 您之前提到、TM4C 甚至在失败状态下不会响应 ping 请求、但我在 Wireshark 捕获中看不到这些 ping 尝试。

是否可以在没有滤波器的情况下进行另一次 Wireshark 捕获、并确保对 TM4C 执行 Ping 操作、以便它显示在捕获中？ 此外、您能否将捕获作为 Wireshark 捕获文件而非 Excel 文件上传？

此致、

达尔顿