• 状态
  • 已锁定 已锁定
  • 个回复 16 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 254 次查看
  • 用户 0 名在线用户
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TM4C1292NCPDT：Lwip 1.4.1堆栈在多小时 TCP 通信后停止响应

admin
Guru**** 1799250 points
Other Parts Discussed in Thread: TM4C1292NCPDT, LM3S6911
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/575366/tm4c1292ncpdt-lwip-1-4-1-stack-stops-responding-after-multiple-hours-of-tcp-communications

器件型号：TM4C1292NCPDT
主题中讨论的其他器件： LM3S6911

我在 TM4C1292NCPDT 芯片上遇到 lwip 栈1.4.1问题。  在 TCP 通信和响应的时间变化(通常至少八小时)后，TCP 端口突然停止响应 TCP 数据包。  使用调试代码和 Wireshark、我可以通过 lwip 堆栈跟踪传入的数据包并将其导入到应用层中、查看在应用层中生成了响应、但响应永远不会退出堆栈、并且无法进行进一步的 TCP 通信。  通过使用 lwip 统计数据、我可以看到、在发生故障的单元上、TCPmemerror 计数器会处理大量事件、成千上万个事件。  发生故障之前、TCPmemerror 不报告任何事件。

UDP 通信是无关联的、也可以通过不同的连接进行 TCP 通信。

多年来、我使用了 LM3S6911 TI 的 lwip 1.3.0端口、而且有数千种器件、但这一问题没有发生。  这似乎是 lwip 1.4.1中 TCP 发送机制的问题。

此帖子看起来很有希望、但实施所概述的修复方案无法解决问题： http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/374100/1316428#1316428

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    好极了-一个非常好的建筑，详细，有爱心的张贴-做得很好！   我不能忍受看到你的写作，“坐吧”。

    在"tcp"问题上远远超出了我的大脑-但以下可能提供了一些帮助。

    • 您注意到、"故障前的可变时间量"-是否可以记录该时间-然后查看(部分)一致性/模式？
    • 可能会发生一些"不必要"的罕见干扰、从而导致干扰？  (附近的电源设备关闭/打开-火花/电弧-强(外部)射频信号等)
    • "可变时间量"可能是由不断变化的"数据数量/负载"导致的、如果足够、则会导致"过流？"
    • 您是否在多个电路板上观察到(完全)相同的故障-更好地将电路板放置在不同位置-减少了单板/位置异常的可能性？  

    同样、在运行时不了解"tcp"知识-是否可以证明它对"完全控制"输入和输出响应非常有用-限制此类基本(简短)事务？  通过这种级别的控制、或许故障时间可能会收敛、这应"指明方向"以发现故障机制...

    公司/我在诊断方面取得了很大的成功-即使是在-以及(有时)特别是在-我们对客户(失败)应用程序一无所知...

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Michael、

    您使用的是哪个版本的 TivaWare？ 我相信，自那时以来，已经作出了两项改变。 您已经突出显示了其中一个。
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Amit、您好！

    这是否意味着(即2次更改)这样的"更改"解决了这一"停止响应"问题？
    如果是这种情况-再次-是否应该更好地宣传/发布更正/修复？
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 CB1

    这两个修复程序都已在 TivaWare 版本中整合。 在论坛中查找这两个修复程序时遇到问题。 其中一个是用户提到的、另一个是我仍在尝试确定的
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    谢谢、Amit。   "修复程序未知或无法快速/轻松找到"是否可能被描述为无效？   这是一个遗憾-很难证明和/或理解...

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 CB1

    我检查了版本说明、并在 QS_IoT 应用中进行了修复。 它们可能与 OP 所描述的不同。

    您好、Michael、

    出现问题时、您是否看到 IP 地址在 lwIP 栈中仍然有效？
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Amit、您好！

    非常感谢您的回答。  以下是您的具体问题的答案：

    TivaWare：我不确定我们使用的原始版本(我将检查一下)，但我们在周末升级到2.1.3.156，并进行了一些测试。  七个或八个测试装置在4-5小时内发生故障、一个测试装置持续一夜、这与我们先前的测试结果相当一致。  和以前一样、我们能够通过 UDP 或不同的 TCP 连接与这些设备进行通信。

    IP 地址：目前我没有办法从外部检查此地址，但我能够打开其他 TCP 连接并通过 UDP 进行通信，这使我相信 IP 地址在 sack 中仍然有效。

    让我知道我可以执行哪些其他测试来帮助您缩小此问题的范围。

    谢谢、

    Mike

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Mike

    感谢您提供详细信息。 如果您增大堆栈大小、那么它是否会影响应用程序的运行时间？
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Amit、您好！


    不幸的是、不是。 我们已测试将堆栈大小从2k 增加到10k、但运行时间没有明显改善。  我已验证我们使用的 TivaWare 的先前版本：2.0.1.11577。

    谢谢、

    Mike

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Mike：

    好的。 是否可以使用简化的代码示例在 LaunchPad 上重现此问题、以便在实验室条件下重现此问题？
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    感谢您的邀请-我将努力为您准备好一些东西。
    Mike
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Michael

    您能否发送项目的 lwipopts.h 文件来提供错误、错误发生时的 Wireshark 日志以及 lwIP 的调试输出？

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Amit、您好！

    有关 lwippts.h 的信息、请参见随附、以及包含一些 lwipstats 信息的屏幕截图。  记录了0个 TCP memerrs 的两个驱动器尚未出现故障。  请注意，TCP xmit + TCP memerr 号几乎等于所有故障驱动器的 TCP recv 号。

    应用程序提交和应用程序恢复号是冻结前我们的应用层接收和传输的 TCP 数据包数-请注意、从几十万个到170多万个数据包的变化。

     此器件上没有 JTAG 端口、因此我们必须通过 UDP 响应从单元中的预编码例程获取所有调试信息。  如果需要、我们可以向该数据包添加更多信息。

    我手头没有 Wireshark 跟踪、但我将得到一条并发布它。

    谢谢、

    Mike

    e2e.ti.com/.../6765.lwipopts.h

  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    屏幕截图上有一个注释... TCP xmit、TCP recv 和 TCP memerr 是16位数字、因此它们会不断地在这一级别的流量中滚动。 如果在第1、6和8行添加 TCP xmit 和 TCP memerr 并获取较低的16位、则会接近这些行上的 TCP recv 编号。
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Michael

    感谢 lwipopts.h 正如我所了解的、TM4C129x 用作 TCP 服务器。 因此、在 TM4C129x 上运行且具有 PC 客户端的 TCP 回显服务器也可用作测试套件。 这是正确的假设吗？ 与 TM4C129x 器件通信时、您在总线上看到的数据包大小也是多少？
  • 0
    TI__Guru**** 1799250 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Michael、

    MEM_SIZE 设置为16K。 在我们的示例中、我们使用64K 作为 lwipopts.h 中的 MEM_SIZE 您能否用相同的方法检查您的示例？