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

在使用 Wireshark 监听所有数据包后、它确认发送器仍然能够传输数据、但接收器根本无法接收任何数据。

我们还尝试通过向 程序添加 EMAC_PC_DIGRESTART 的位切换来组合修复。  遗憾的是、它不起作用、只能完成断开连接。  不过、在 CCS 中进行切换似乎仍会重新启动通信。

您能否详细说明 EMAC_PC_DIGRESTART 的具体作用？ 下面是我在上面找到的代码片段：

该位允许用户重新启动 PHY。 将该位置为有效将导致
PHY 逻辑和内部寄存器、用于复位至初始条件。 该位可以
不影响由 EMACPC 寄存器提供的配置位
在芯片复位后存储在 PHY 中。 以启动软复位至
PHY、该位必须写入1、然后再次写入0。

这个位是否有任何时序要求？

您好！

是的、我们将使用 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)； 

[引用 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 通过以太网驱动程序离开的情况。  

它实际上非常相似、请参阅下面的(摘自 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 寄存器。  不过、这会有点偏离主题、因为除非我们实际拔下并重新插入电缆、否则链路不会切换。  触发中断时、检测链路上升/下降工作正常。

[引用 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｝帖子。)

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

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

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

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

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

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