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.

[参考译文] RTOS/TM4C129XNCZAD:是否有办法复位以太网 PHY 和 NDK?

Guru**** 2468560 points


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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/669871/rtos-tm4c129xnczad-is-there-a-way-to-reset-ethernet-phy-and-ndk

器件型号:TM4C129XNCZAD

工具/软件:TI-RTOS

我有一个用例、其中 TM4C 微控制器位于封闭环境中、外部仅提供以太网访问、而对复位开关的访问受限。  微控制器运行 TI-RTOS 和 TI NDK。  间歇性地(大约每周一次)、以太网连接将断开、这意味着外部世界中的器件不再能够通过以太网与微控制器通信。  Cisco 路由器可以看到来自微控制器的定期 DHCP 请求,这表示链路仍然存在到微控制器,但 DHCP 响应没有到达微控制器。  重置微控制器会使以太网连接恢复、但这不是一种长期解决方案。  没有重启微控制器、是否有办法只复位以太网 PHY 和 NDK?  由于对微控制器的访问有限、调试选项非常有限。  是否有任何建议可帮助确定这是网络配置还是 NDK 的问题?  重置微控制器重新建立以太网链路这一事实让我倾向于相信 NDK 存在问题。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    NC_NetStop()将关闭网络。 您可以使用 NC_NetStart()再次启动它。

    您对找出根本问题的兴趣似乎不大。 是否要修复小工具?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    实际上、我确实想修复我的应用、但不知道从哪里开始、因为我不能在其中放置 JTAG 探针并开始调试。 在封闭环境中、我只能依赖日志。 您对如何进行调试有什么建议吗?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    调试很有启发性。 "关闭再打开"令人难过、但有时是合理的。

    DHCP 是一个4步过程。 器件是否通过请求响应报价?

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

    对于已经在客户手中的产品、"关闭并再次打开"为我节省了调试时间并找到根本原因。  

    我已附上客户的 Wireshark 捕获。  当检测到链路丢失时、微控制器当前进入自动 IP 模式、您可以看到微控制器正在从169.254.4.5 IP 地址发送 DHCP Discover。  网络会看到请求并使用 DHCP 服务进行响应。  但是、微控制器不接受该服务、并继续发送 DHCP 发现。  我计划尝试禁用自动 IP、以便微控制器不会获得169.254.4.5地址。  不确定这是否妨碍了它查看 DHCP 服务。

    e2e.ti.com/.../CAMERA25.zip

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我希望 DHCP 发现数据报的源地址为0.0.0.0。 奇数。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    MAC 地址是否看起来正确? OID 是 IEEE 注册机构,DHCP 提供的 IP 将与查找源不同。

    此捕获与您的设备之间是否有路由器?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    微控制器的 MAC 地址正确。 如果您注意到、IP 地址的最后2个字节与 MAC 的最后2个字节相同。 当微控制器在一段时间后未获得有效的 DHCP 响应时、微控制器将恢复为 APIPA 并为自身选择 IP 地址。 我们特别使用 MAC 地址的最后2个字节作为初始 APIPA IP 地址中的2个 LSB、以避免 IP 冲突。 这说明了微控制器使用169.254.4.5 IP 地址的原因。 这向我表明、在捕获时、微控制器在一段时间内无法访问 DHCP、并已恢复到 APIPA。 在 APIPA 模式下、微控制器仍会定期发出 DHCP 请求。

    由于我不熟悉网络设备和拓扑、我假设他能够从路由器本身捕获数据。 这是我可以向客户询问和澄清的内容。

    通过在微控制器中禁用 APIPA、微控制器将不会进入使用 APIPA 地址发送 DHCP 请求的状态、希望该状态能解决问题。 但这有点属于 WAG。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Peter、

     在 DHCP Offer 帧的 BootP 有效负载中,客户端发送的 IP 地址为0.0.0.0,但服务器正在尝试租用新的 IP 地址10.101.155.2。 我不知道客户端是否拒绝接收此新地址、而是保留前一个地址、因此不发送 DHCP 请求阶段。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    当事情正常时、复位后的交换看起来是什么样子?

    为什么 Offer 255.255.255.254中的子网掩码? 通常,以10开头的专用网络 IP。 掩码为255.255.0.0。 我尝试使用此掩码启动服务器,但加载失败。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    查尔斯

    在这种情况下、微控制器是客户端。 如何判断微控制器是否没有获取 IP 地址? 由于 DHCP 几乎完全由 NDK 处理、是否有办法确定 NDK 是否获得 DHCP 服务? 我的代码在"网络 IP 地址挂钩"中设置了回调、并使用那里分配的任何 IP、只要 fADD 大于0即可。 我认为我无法控制 DHCP 请求。 这完全由 NDK 处理。 我是否可以通过任何方式了解这一点?

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

    有关报价上子网掩码的良好信息。 我将更深入地探讨这一点。 问题可能出在交换机或路由器。

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

    请允许我注意公司/我与 Peter Re 达成的完全一致意见:"调试的巨大价值"。

    您说、您的"系统掌握在(远程)客户端的手中/拥有"-作为"不进行调试的理由!"    您是否有可能 "未能构建额外/备件/备份设备"、以便您可以保留多个设备、以便进行持续测试/分析、甚至更换?    如果为 true -您(可能)创建了自己的 gifows!

    如果为 true -不应该 "您构建的附加单元(或从客户端恢复1)"-迅速具有最高优先级?     (实现更舒适、更高效的本地调试!)

    虽然这是" 一个特定的问题已被识别"、但(其他人)是否还没有提交或逃避通知等待您? 再说一次-调试至关重要!

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

    您将会偏离评论的基础。 "在(远距离)客户的手中/拥有"是指已发布且在现场的产品。 这意味着我们在现场拥有超过一千种产品、而这种故障仅发生在特定(尽管很大)客户身上。

    问题仅在用户环境中发生、现场不可重现。 是的、我们有内部单元... 为什么我甚至在回答您的 CB1后???
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [报价用户="Yan Li29"]对于已在客户手中的产品[/报价]

    您的上述报价(并非"合理")是否确实表明您的产品与客户驻留?   那么,这种评论怎么能像你大声宣称的那样“离开基地”呢?

    您还会注意到、"现场有一千个产品、此故障仅发生在特定(尽管很大)客户身上。"   这是关键信息-不是吗?   而不是先前提供的。

    你还说(现在),"是的,我们有单位在房子里"--然而(似乎)不能在早些时候清楚地介绍--这不是真的吗?

    至于您(相当不友好)、 "您为什么要回答"-只有您可以提供该答案。

    您是否有智慧/经验认识到" 我提出的许多/大部分问题-供应商代理提供(必要)的放大和澄清!"、这一点尚不确定!    (谁代表了您最受人惊喜和最快的成功之路!)    

    一个、"基地外"-可能不是我!    所有"证据中的事实"都表明我的建议是"公平合理"。  你的“金星”——不是太多!

    尽管您 的"最高层"攻击-我确实希望您的问题能够得到解决...

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Yan、
    我更想猜测、而不是声明客户端(MCU)需要之前的 IP 地址、而不是新的 IP 地址。 DHCP 是从 Discover->Offer->Request->Acknowledge 开始的四步过程。 在 Wireshark 捕获中、客户端要么没有从服务器收到报价、要么不希望收到报价。 也许我在早些时候做出了错误的猜测。 MCU 可能处于未正确接收报价的状态、因此尝试重复发送 DHCP 发现。
    我对 NDK 没有足够的了解。 我将向我们的 TI-RTOS NDK 专家寻求帮助。 请等待他们回复。 在接下来的两天内、我将无法监控此主题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    网络 IP 地址挂钩与静态设置 IP 时获得的回拨相同。 我认为它不会帮助您专门调试 DHCP。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    调试堆栈本身可能比较复杂。 NDK 使用预构建库。 您自己构建库的过程如下: processors.wiki.ti.com/.../Rebuilding_The_NDK_Core_Using_Gmake

    我没有看到在 CCS 中调试 NDK 堆栈的方法(或有理由查看)、但它可能就像告诉项目源文件的位置一样简单。

    是否可以找到重新创建 DHCP 服务器产品的方法? 如果无法重新创建该情况、我将看不到调试堆栈的值。

    我怀疑您确实想要修改堆栈、但这可能有助于您发现问题。 修改堆栈似乎有风险。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    查尔斯

    明白。  我将等待你的答复。  同时、我将看到我是否也可以在我所在的位置重现此问题。   

    谢谢你。

    -Yan

    BTW、这位 CB1_mobile 人物是谁?  似乎是一个爬虫程序或有人在试图获得高声誉的论坛上进行了滥发。  我检查了他最近的5个帖子、发现其中没有一个帖子提供任何价值。

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

    感谢您提供的信息、非常感谢您的帮助。 我将尝试在现场重新创建此问题。 我已经向客户发送了一个版本、其中删除了 APIPA、恢复机制和其他记录功能。 希望这能让我更深入地了解这个问题。

    我同意、调试堆栈现在不是一个选项、因为我甚至无法在内部重新创建问题、并且堆栈中没有烟枪。

    -Yan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Yan、
    我将向我们的 NDK 专家发出命令、看看他们是否可以提供一些意见。 如果有一些延迟、请深表歉意、因为如果对网络和 NDK 没有很好的了解、问题可能不会很直接。 我现在还在办公室外(实际上现在就在医院里)。

    我觉得 CB1有一些误解。 他知识渊博、是论坛的长期贡献者。 也许他对您说的话会误解他帮助您加速解决问题的意图。 让我们重点关注问题解决、而不是关注谁是 CB1。 感谢您的理解。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Yan、

    您能否确认正在使用的 TI-RTOS 和 NDK 版本? 如果您可以共享用于编译代码的 TI-RTOS 配置(.cfg)文件、这也很方便。

    此外、我同意 Peter 之前的评论、最好是在同一环境下工作时获取 Wireshark 捕获 DHCP 交换在复位后的外观。 这可能有助于对问题进行一些了解。

    此致、
    文森特
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Vincent:

    e2e.ti.com/.../AppMaster.zipRTOS版本为2.12.1.33。  随附 CFG 文件。

    -Yan

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

    文森特

    随附良好工作案例的 Wireshark 捕获。  查找 DHCP 以查找10.101.155.2

    -Yane2e.ti.com/.../CAMERA25_5F00_good.zip

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

    我正在检查我们的打印机、以了解我的(促销)"爬虫程序"是否可以添加到最新的名片中。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用用户="Yan Li29]Wireshark 捕获良好的工作案例。[/quot]查看 CAMERA25.pcap (BAD)和 CAMERA25_gON.pcap 文件、我看不到 DHCP 服务器上的 DHCP Offer 消息在良好和不良案例之间的任何差异。

    一旦设备处于故障状态、它是否响应任何以太网消息? 例如,它是否响应原始 DHCP 服务器分配的 IP 地址或自动分配的 IP 地址上的 ping?

    从问题说明中,不确定症状是否只是设备在 DHCP 租用续约后不接受 DHCP 服务消息,或者无法与设备通信。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢 Yan 提供的信息。 我看到 DHCP 租用时间设置为从 Wireshark 捕获后8天。 这与断开连接的时间是否匹配? 在您的原始帖子中、您提到了"大约每周一次"。 我们想知道该问题是否由即将到期的租约引起。 是否可以将服务器上设置的 DHCP 租用时间更改为较短的时间(例如几分钟)并查看是否发生断开连接? 我们还将在结尾处重复此操作、并告知您我们是否可以看到问题。

    另一件有趣的事情是在发生故障后通过 telnet 连接到 MCU 并执行一些检查(例如内存不足)、但我看不到.cfg 文件中配置的 telnet 服务器。 我想无法在发生故障的设置上运行修改后的配置、对吧?

    此致、
    文森特
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Vincent:

    客户报告微控制器在随机时间 DHCP 故障、平均时间为每周一次。 我仍在等待他们返回到我的"DISABLE APIPA"测试的结果。

    当 DHCP 失败时、客户无法 ping 微控制器。 因此,即使有 telnet 服务器,telnet 访问微控制器也会失败。

    -Yan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    切斯特、

    当设备处于故障状态时,它不会响应任何 ping,但仍在尝试 DHCP。 从错误场景的日志中、我们知道设备仍然能够传输、因为它仍在发送 DHCP 发现。 遗憾的是、我没有想到一种好的方法来确定器件是否未收到该器件的报价、以及该堆栈是否拒绝了该报价。 我被告知的唯一一点是、重新启动后、如果没有任何布线更改、DHCP 将再次工作。

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

    感谢您的更新。 如果未能在少于租赁期限的时期内发生故障、则这就排除了我们的理论。

    处理 DHCP 交换的关键函数是 C:\ti_tirtos_tivac_2_12_01_33\products\NDK_2_24_02_31\packages/ti\NDK\nettools\dhcpsm.c 中的 StateSelecting() 它构建并发送 Discover 数据包、然后进入循环、等待 Offer 数据包3秒。 如果未收到报价、则发送另一个"发现"数据包重试。 这似乎与"错误"捕获中的行为相匹配。

    两个可能的假设是:
    1.收到包含报价的数据包,但该数据包已损坏/无效,因此 dhcpVerifyMessage()将拒绝该数据包。
    2.未接收到包。 dhcpPacketReceive()中的 recv()调用返回-1。

    是否可以在其设置上运行修改后的二进制文件来解决此问题?

    此外、我们尝试通过在获得 IP 地址后拔下以太网电缆来重现问题、但到目前为止、我们还无法看到问题。 DHCP 服务是否在其应用程序中重新启动?

    此致、
    文森特
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Yan、

    这个上的状态是什么?

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

    我们发现、当我们在器件上禁用 APIPA (auto-IP)时、问题就会消失。 设备和路由器之间有一个交换机。 我怀疑当设备进入 Auto-IP 状态时、交换机不再向设备转发 DHCP 提供的服务。 我想说这个问题现在已经解决了。 感谢大家的帮助。

    -Yan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    很遗憾听到 APIPA 不能正常工作。 TI 的演示项目 Enet_IO 获得具有相同 APIPA 169.254的静态 IP。 0.0/16 IP 范围。 该项目使用 lwip。