[参考译文] TM4C129ENCZAD：以太网通信因缺少错误消息而停止

您好！
那么、这两块板连接到 LAN 中、没有任何集线器或交换机？ 由于您说电缆制作不良、因此我建议您更换为不同的电缆、然后重试。 如果您的工作台上有两块板、您实际上不需要80m 电缆。 查看更换电缆是否可以解决问题、因为您说它有时工作数小时。

您是否使用静态 IP 地址或网络上的 DHCP 来分配 IP 地址？

正确、两个板直接相互连接。

遗憾的是、我必须为此应用使用这条专用的90m 长电缆。 我希望从其中一个中断或一个我可以轮询的寄存器中获得一个错误、这样我就会知道发生了一个故障。 我知道应该使用更好的电缆、但良好电缆上未检测到的故障对于我的设计来说仍然是不利的。 如果电缆制作太差、我本来以为链路会掉线、但可能我还不能完全理解这一特性。

当前在两个设备上使用静态设置的 IP 地址。 两台设备的网络上不存在 DHCP 服务器。

作为更新、我还读取了以下 MAC 寄存器以确保数据已被 MAC 计数：
EMAC_TXCNTGB
EMAC_TXOCTCNTG

它们都在故障后递增。

即使 Devkit 已发送数据、EMAC_RXCNTGB 也不会递增。

任何其他用于调试的 IDES 都很棒。

谢谢

在继续测试的同时、我们更改了设置以允许将 PC 包含在混合设备中。 这意味着我们已经修改了设置位、中间现在有一个开关。 所有 IP 地址都是静态的。

遗憾的是、交换机不允许我们查看两台设备之间的流量、但我订购了一台具有端口镜像的设备、该设备应在一天结束前到达。 有趣的是、在我拔出连接到 TM4C 的以太网电缆时出现故障后、会检测到链路断开。 当插回链路时、检测到链路连接并传输 ARP 帧。 PC 能够看到此帧、确认发送器仍在 TM4C 上工作。

我们还将开发套件设置为网关、以便 PC 可以按自己的方式发送 ARP 帧、开发套件能够接收响应并向 PC 发送响应。

当将 PC 的网关地址设置为 PC 的 TM4C ARP 帧时、电路板不会接收到该帧。

这使我们相信 TM4C 的接收端存在问题。 我们已经尝试了以下操作：
已检查 EMAC_DMARIS_RS - 0x03 -正在运行：正在等待接收数据包
已切换 EMAC_CFG_RE -无更改
已切换 EMAC_DMAOPMODE_SR -无变化

使事情再次发生的唯一方法是切换 EMAC_PC_DIGRESTART。

当新开关出现并显示任何新内容时、将再次更新。

您好、Roque、

是否使用 LWIP 1.4.1？ 也许32位突发速率可能会淹没 DMA 描述符、从而导致 RXD 缓冲区在一端或另一端不可用(RBUN)。 建议尝试16字节 DMA 突发缓慢传输。 我们发现连接状态寄存器向下问题 tiva129.c 抽象层受到语法设计的困扰、因此请检查代码。

也许可以在调试的异常中断中添加一个 UARTprintf()调用、这有助于查看 EMAC0在所有异常中断分离时正在处理的异常中断。 通常情况下、它最终会导致多件事情、而不仅仅是一件造成混乱的事情。 特别敏感的是对 rignbuffer.c 的阻止、布尔标志的执行速度比缓慢的 ass 宏快得多。

您好！

是的、我们将使用 lwip 1.4.1。  遗憾的是、我们没有获得任何 RU 中断。  感谢添加调试打印输出的提示；我们使用的是 Segger 调试器、该功能可轻松添加到终端输出中。  我们一直在保持一个正在运行的计数器来计数正常和异常中断、并且 RU 从未弹出。  但是、我们开始从我可以看到的内容中获取 OVF (Rx 溢出)、这意味着 Rx DMA 缓冲区在能够将数据传输到描述符指示的缓冲区之前会受到数据溢出的影响。

接收缓冲区在帧接收期间发生溢出。 如果
部分帧被传输到应用程序、即溢出
状态在 RDES0[11]中设置。

我不知道为什么会发生这种情况、但当驱动程序丢弃帧时、器件似乎可以很好地从它恢复。  即使该计数为0或高达10、也会发生故障。  

周末、我们在交换机和 STM32设备之间移动了90m "劣质"电缆、并将其设置为10Mbps 全双工(tm4c 上的设置相同)。  将 tm4c 放在长45米的优质电缆上。  两个器件仍在相互通信、只是中间的开关。  在我们手动停止测试之前、它已经运行了48小时以上。  然后、我们将 tm4c 更改为半双工、三小时后失败。  

在此测试中、我必须想知道在故障情况发生后是否有更好的方法来调试 MAC/PHY？ 也许 MAC 正在丢弃帧、而不是通过 RX DMA 线发送？  

[引用 USER="Roque Obusan"]我们一直保留一个正在运行的计数器来计算正常和异常中断，RU 从未弹出[/引用]

 如果 DMA 接收缓冲区溢出发生 、这似乎有点奇怪、引擎应该使 RU 跳闸。 确保报告十六进制非 整数异常状态错误。 可能甚至 会报告 PHY 中断、因为它在 TCP 负荷时似乎指示了一些奇数代码。

[引用 USER="Roque Obusan"]也许 MAC 正在丢弃该帧，而不是通过 RX DMA 线路发送该帧？[/引用]

如果 应用程序占用大量处理器时间 并使用 RST 进行响应 (即使 帧 缓冲区设置相当小) 、LWIP 喜欢丢弃帧、并且在发生这种情况时孤立的 PBUF 始终为 NULL。 也许可以 在(lwipopts.h)中打开 LWIP 调试统计信息、然后在  应用程序层 错误陷阱可能调用的位置放置一个[stats_display()；]。

相信我 、可能会面临更多问题。  一种似乎困扰 LWIP 的方法是 TCP 间隔 计时器 正在向快速(TM4C 150 DMIPS)移动一位、并可能导致 TCP 丢弃帧。

[引用 user="BP101"]

 如果 DMA 接收缓冲区溢出发生 、这似乎有点奇怪、引擎应该使 RU 跳闸。 确保报告十六进制非 整数异常状态错误。 可能甚至 会报告 PHY 中断、因为它在 TCP 负荷时似乎指示了一些奇数代码。

[/报价]

我也觉得奇怪。  已确认、请参阅以下代码：

if (ui32Stats & EMAC_INT_NORMAL_INT)
｛
++netif->_DriverStats.ui32AbnormalInts；

netif->CheckAndIncCount (nitif->_DriverStats.ui32TXStopped、ui32Status、
EMAC_INT_TX_STOPPED)；
netif->CheckAndIncCount (netif->_DriverStats.ui32TXJabber、ui32Status、
EMAC_INT_TX_Jabber)；
netif->CheckAndInCount (netif->_DriverStats.ui32RXOverflow、ui32Status、
emac_int_RX_overflow)；
netif->CheckAndIncCount (netif->_DriverStats.ui32TXUnderflow、ui32Status、
emac_int_tx_underflow)；
netif->CheckAndIncCount (netif->_DriverStats.ui32RXNoBuffer、ui32Status、
emac_int_RX_NO_buffer)；
netif->CheckAndIncCount (netif->_DriverStats.ui32RXStopped、ui32Status、
EMAC_INT_RX_STOPPED)；
netif->CheckAndIncCount (netif->_DriverStats.ui32RXWatchdog、ui32Status、
emac_int_RX_watchdog)；
netif->CheckAndIncCount (netif->_DriverStats.ui32TXEarlyTransmit、ui32Status、
EMAC_INT_EARLY_Transmit)；
netif->CheckAndIncCount (netif->_DriverStats.ui32BusError、ui32Status、
EMAC_INT_BUS_ERROR)；
｝ 

无效 CheckAndIncCount (uint32_t&计数器、
const uint32_t stat、
const uint32_t mask)
｛
IF (统计和掩码)
++计数器；
｝ 

上述代码可在以太网驱动程序的中断处理程序中找到。  

在这些中断传输过程中，我们目前看到处理器的空闲时间大于95%。  当故障发生时、中断停止完全触发。  我们甚至会监控以下寄存器的活动：

EMAC_RXCNTGB (良好和不良帧的以太网 MAC Rx 帧计数)

EMAC_RXCNTCRCERR (CRC 错误帧的以太网 MAC Rx 帧计数)

EMAC_RXCNTALGNERR (校准错误帧的以太网 MAC Rx 帧计数)

EMAC_RXCNTGUNI (良好单播帧的以太网 MAC Rx 帧计数)

活动完全停止。  当我们看到发射的传输时、等效以太网 MAC TX 计数器会递增并通过 Wireshark 验证。

BTW：EMAC_CONFIG_BO_LIMIT_16 非常小、我们通常为10/100双工设置1024字节。  我们禁止互联网 巨头导致缓冲器问题、32位突发使谁知道 LWIP 是否会引发类似的蜂播？

//RX 帧> 1518字节巨人、丢弃所有帧> 2048字节。
EMAC_DMAOPMODE_DGF)、2048)； 

也许 kiss 代码会指示您的问题异常。

似乎有必要  启用调试 、并且我们禁用 TIVa129 HAL 调试。  TI 为 谁知道原因而使其处于启用状态(如果是调试)- 只需重命名(def Debug)以检查 PBUF、然后将其 关闭。#if NETIF_DEBUG。

 也许 Kiss 更好？ 该代码始终报告十六进制寄存器代码、RU/TU 是一个令人厌恶的小位。

SysPrintf (">异常 INT 状态-->：%x\r\n"，ui32IntStatus)； 

我理解您要说的内容、但我认为上述代码也可以用来捕获异常中断。 它还会将错误仔细地存储到我们可以从 CCS 中看到的易于查看的计数器中。 这使得在长时间登录时很难错过。

我想我们在这里缺少的是、来自 MAC 的 RX 计数器完全停止。 此外、RX 中断停止一起触发。 我想相信这是一个堆栈错误、但我根本看不到帧到达。 例如、在故障发生之前、我可以执行程序、但仍然看到 Rx 计数器寄存器递增。 在出现故障后、当程序停止并运行时、计数器停止。

[引用 user="Roque Obusan"]它还会仔细地将错误回收到易于查看的计数器中，我们可以从 CCS 中看到这些计数器

您是否不会 假设您的自定义计数器在所有情况下都有效？ 您必须松开什么？  丢弃帧 赌注是 由于丢失的数据包(P=Null)、短帧或长帧而产生的异常中断。 您是否打开了 LWIP 调试统计信息？    一旦您看到源文件/断言错误消息在帧丢失时发布、一切都将变得更加清晰。   

也许您的 DMA 引擎 的变化与 成熟而真实的情况有所不同、婴儿步进和大步向前是最佳的推荐做法。  同样、我们从未有过32 位突发、更真实的16位 TX/RX 突发 @ LWIP 的 TX-2：1优先级、尤其是  在回调中禁用 TCP Nagel 模式(无延迟)时。   

我们的观点 是 、64位阈  值在某些 DMA 突发模式下不起作用、如果您研究 寄存器工程文本、则很明显会忽略这些阈值。

如果 RDP 也 用于 DNS 等、可能添加 TCP 客户端优先级：

//设置 TCP 连接优先级。
tcp_setprio (PCB、tcp_PRIO_MAX)； 

我启用了 lwip_stats。  它们支持我们的发现、即 Rx 数据包甚至不会将其放入链路层。  因此、它们甚至不会将其放入 lwip 堆栈中。  我们还尝试了从4到32的 DMA 阈值、但没有一个可以缓解这一问题。  故障八年后、MAC 计数器(硬件)不能递增、这进一步支持了这一点。

我们成功地使用了长45米的优质电缆、48小时内没有任何问题。  我的问题是、当我们使用质量较差的电缆时、结果似乎是 RX 通道断开而没有设置错误位。  换用电缆时、我们能够可靠地使故障发生(Rx 通信仅停止)。  我明白、我们使用质量较差的电缆进行测试似乎很奇怪。  我们的设计的现实情况是、我们需要具有已知的故障模式、以便可以将其传达给操作员。  当前 RX 通信停止、并且 MAC、PHY 或 DMA 中没有错误位被置位。  

此外、TX 通道仍然继续运行、通过以下步骤进行验证：

1.只拔下以太网电缆，链路断开，由 phy 中断触发验证，通知链路状态发生变化 并读取 EPHYSTS 寄存器

2.插回以太网电缆、实现链路、通过 PHY 中断触发验证、通知链路状态更改并读取 EPHYSTS 寄存器

3. lwip 收到链路通知并触发 arp 帧，由 lwip_stats 在 etharp 计数器上递增 xmit 验证，由 PC 上的 Wireshark 进一步验证

但是、即使以这种方式重置链路后、Rx 仍然不起作用。  使 Rx 正常工作的方法如下：

完全系统复位、包括固件和 lwip 的复位

2.切换 DIGRESTART 位 EMACPC 寄存器。  我可以告诉它只复位内部 PHY 中的逻辑和寄存器。  这不会重置固件和 lwip 堆栈。  但数据接收再次开始。  需要注意的一点是、它仅在我们切换 CCS 中的位时才会工作。  文档不提供时序信息、因此我们在将其插入程序时可能会错误地使用它。

感谢您的帮助。

[引用 user="Roque Obusan"] lwip 收到链路通知并触发 arp 帧，由 lwip_stats 在 etharp 计数器上进行验证，由 PC 上的 Wireshark 进一步验证

您的应用层可能会导致 LWIP 甚至 EMAC0出现问题。  同意 活动 LED 随机闪烁 异常 RU 、 似乎 表示 DMA 引擎 TX FIFO 尝试发送数据包、即使它 处于 TU 寄存器状态。 日志卡纸会在河上发生这种情况、 导致水流严重溢流。  

请发布 TIVa129.c HAL 链接状态加载 函数、因此我们可能都位于此处的同一页面上。

为了进一步证明这很可能不是 lwip 问题、我们在夜间运行以下测试：

1.定制板连接到运行优质90m 电缆的 stm32f4开发套件-目前仍可工作16小时以上

2.自定义电路板连接到运行质量较差的90m 电缆的 stm32f4开发套件-几分钟内出现故障

3.带有修改固件的 TI 开发套件连接到运行质量较差的90m 电缆的 stm32f4开发套件-几分钟内失败

4、TI 开发套件带有修改后的固件、连接到运行优质90m 电缆的 stm32f4开发套件-目前仍可工作16小时以上

5、stm32f4开发套件通过劣质90m 电缆连接到交换机、定制板通过优质90m 电缆连接到交换机-目前仍可工作16小时以上

我要再次重申、切换 DIGRESTART 位会使接待重新开始、然后再失败。  如果应用程序或 lwip 导致这些错误、则所有这些测试都应该失败。  相反、我们看到的模式是、劣质电缆(速度仅为10Mbps)和 TI 内部 PHY 出现故障。  将这些质量较差的电缆连接到 PC 后、我们可以在几乎全速10 Mbps 的速率下毫无问题地传输数据。  我们的代码在10Mbps 附近的位置传输、但在200kbps 附近的位置传输。  质量差的电缆出现故障时、我们没有问题、我们的问题是、我们无法找到任何错误来表明问题已发生。  理想情况下、DMA、MAC 或 PHY 上的故障位之一将被置位、以便我们能够积极识别问题。

根据您的请求、我已发布以下链接相关代码：

//读取中断状态、因此我们知道
const uint16_t misr1 = ROM_EMAPPHYREAD (EMAC0_BASE、PHY_PHYS_ADDR、
EPHY_MISR1)；
const uint16_t misr2 = ROM_EMAPPHYREAD (EMAC0_BASE、PHY_PHY_ADDR、
EPHY_MISR2)；
const uint16_t bmsr = ROM_EMAPPHYREAD (EMAC0_BASE、PHY_PHY_ADDR、EPHY_BMSR)；

//链路状态是否已更改？
if (misr1 & EPHY_MISR1_LINKSTAT)
｛
if (bmsr & EPHY_BMRS_LINKSTAT)
｛

TCPIP_INSTRUMAS (((TCPIP_callback_fn) nTIF_SET_LINK_UP、&BMCIfInstance
)；
++debugcounter.linkup；
_BLinkActive = true；
｝
否则
｛
TCPIP_callback ((TCPIP_callback_fn) netif_set_link_down、
&inst->_NetIfInstance)；

++debugcounter.linkdn；
_BLinkActive = false；
｝
｝ 

然后由 lwip 处理 ARP 帧的传输。  我们可以成功地跟踪 ARP 帧通过 MAC 计数器、过程中的断点以及 Wireshark 通过以太网驱动程序离开的情况。  

围绕链路上升/下降状态条件、这是完全不同的(Tiva_129.c) HAL 代码。 您是否重写了 Tivaware DMA 引擎 HAL 的这一部分？ LWIP 对于 EMAC0链路状态寄存器处理非常敏感、尤其是在链路向上/向下弹出时。

它实际上非常相似、请参阅下面的(摘自 tivatm4c129.c)

ui16Val = EMACPHYREAD (EMAC0_BASE、PHY_PHY_ADDR、EPHY_MISR1)；

/*读取当前 PHY 状态。 *
ui16Status = EMACPHYREAD (EMAC0_BASE、PHY_PHY_ADDR、EPHY_STS)；

/*链接状态是否已更改？ *
IF (ui16Val 和 EPHY_MISR1_LINKSTAT)
｛
/*现在链接是上行还是下行？ *
IF (ui16Status 和 EPHY_STS_LINK)
｛
/*告诉 lwIP 链接已启动。 */
#if no_SYS
netif_set_link_up (psNetif)；
#else
TCPIP_callback (((TCPIP_callback_fn) netif_set_link_up、psNetif)；
#endif

/*在本例中，我们会进行浏览，因为我们可能需要重新配置
* MAC 取决于速度和半双工/ fui32l 双工设置。
*/
｝
其他
｛
/*告知 lwIP 链接已关闭*/
#if no_SYS
netif_set_link_down (psNetif)；
#else
TCPIP_callback (((TCPIP_callback_fn) netif_set_link_down、psNetif)；
#endif
｝
｝ 

另请参阅数据表中的注释：

链接状态
值描述
0未建立链路。
已建立有效链路(对于10 Mb/s 或100 Mb/s 操作)。
该位与 EPHYBMSR 中的链路状态位重复
寄存器(PHY 偏移量0x001)。
1
读取 EPHYSTS 寄存器后、该位不会清零。

我们只需使用 EPHYBMSR 寄存器、而不是 EPHYSTS 寄存器。  不过、这会有点偏离主题、因为除非我们实际拔下并重新插入电缆、否则链路不会切换。  触发中断时、检测链路上升/下降工作正常。

我们现在已经解决了一个变通办法、遗憾的是、由于仍然缺少错误消息、我们的工作可能会延迟高达500ms (在当前实施中)。

当我们从 Mac Rx 计数器中看到至少500ms 的活动时、我们将重置 Mac、phy 和 DMA。 即使在135m 的不良质量电缆上、此解决方案也是令人满意的。 当我们找到合适的稀释液时、我们将继续调查并更新此主题。

感谢您的帮助。

[引用 user="Roque Obusan"]不过，这会有点偏离主题，因为除非我们实际拔下电缆并重新插入电缆，否则链路不会切换。

远高于开机自检回呼您说过、当切换  至较低质量的电缆时、EMAC 在插入后停止接收数据。 此论坛 通常支持供应商 HAL、您没有提及 您的自定义更改 、这让我想知道您还有哪些更改。

请尝试使用供应商 的 DMA 描述符 HAL 来比较您的调试跟踪结果是相同或不同的。 似乎比   POR 或 链路上升/下降之后更多次地调用 PHY 中断触发、尤其是在 RU/TU 标志期间 、EMAC 需要在 HAL 中进行特殊处理、以便 在 DMA 引擎由于各种原因停止时重新启动它。  召回 问题 报告的链路状态检测 在读取 STS 寄存器时有效 、并返回 到使用 BMSR。  然后发现 的链路 状态 测试  使用 逻辑 (!) 未能正确通知 LWIP 初始已关闭，   二进制寄存器的按位(~)工作效果要好得多。

BTW：您的 IDE 调试 硬件跟踪宏单元可能并不总是实时或完全取决于 JTAG 停止的位置。 这是我对 EMAC 的沮丧、尝试在 CCS 调试中调试中断处理程序几乎没用。

只是想发布此问题的更新、以防将来有人遇到此问题：

我们购买了基于 TM4C129XNCZAD 的开发套件(DK-TM4C129X)、该套件允许使用内部和外部 Phy、并安装 了基于 DP83822I 的 ehternet phy (DP83822EVM)。  固件的唯一更改是将接口从内部 phy 更改为 MII。

我们的电缆质量很差、没有任何 ISes、运行48小时、并且在计数。  我们将修改我们的定制板、并将更改以包含此 PHY。

嘿、我的朋友首先检查这一点、因为 最近对 EMAC0行为的更新可能是定制 PCB 布局问题？

FWI：如果定制 PCB 以太网差分对不均匀或 TXD 与 RXD 对接近间隔(1.27mm)、则可能会发生奇怪的情况 、例如 串扰等。

/cfs-file/__key/communityserver-discussions-components-files/908/TI_2D00_TM4C_2D00_PCB-layout-facts.pdf

[引用 user="BP101"]如果您的定制 PCB 以太网差分对不均匀或接近间隔 (1.27mm)的 TXD 到 RXD 对，则可能会发生奇怪的情况[/引用]

真的吗？   这难道不是48小时的“飞向面”“正常运行”吗？   

此类硬件/布局问题在经历了如此多(成功的运行时间)之后不太可能揭示它们的存在！

感谢海报 Obusan 的坚持和开发真正的解决方案！

(我们注意到您(独自)"喜欢"您自己的｛3月15日下午6：47｝帖子。)

海报制作了定制 PCB、对您的问题回答"否"如果 EMAC 差分对在应力分析下降级、48小时与信号质量无关。 谁知道定制 PCB 是多层、还是遵循推荐的正确设计布局。

我们已尝试使用 TI 开发套件、请参阅上面的一些博文：

3.带有修改固件的 TI 开发套件连接到运行质量较差的90m 电缆的 stm32f4开发套件-几分钟内失败

4、TI 开发套件带有修改后的固件、连接到运行优质90m 电缆的 stm32f4开发套件-目前仍可工作16小时以上

(强调已添加至 ti dev 套件)

我所说的修改后的固件包含完全相同的 lwip 堆栈和以太网驱动程序、但由于它无法连接到我们修改固件的相同外设、因此无法返回设置的有效负载而不是获取的数据。

至于信号完整性、我们不仅遵循了 TI 的建议、还购买了信号完整性软件来确认正确的阻抗和最小的串扰。  与此定制板上的其他一些信号相比、以太网速度相当低。