Other Parts Discussed in Thread: AM2434
器件型号: AM2434
你(们)好
我们正在使用 am2434 ind_comms_sdk_am243x_09_02_00_24 SDK 在定制电路板上进行一致性测试、我附上了错误、根据之前的建议、我们使用 product_code、产品名称、器件版本和供应商 ID 更新了代码)
我们是否需要注意或更改代码的任何其他事项。


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.
尊敬的 Yashaswini:
该错误可能表明您尚未加载.SOC 文件。 您需要像针对.EDS 文件一样调整.SOC 文件。 要执行此操作、只需 通过“STC Editor“面板->添加->(选择您的 SOC 文件)->确定(添加菜单)->确定(“STC Editor“菜单)打开您的.SOC/.STC 文件
如果您没有.SOC 文件、则可以 从 EIP 示例作为模板开始。 例如、通用器件的 SOC 文件可以在以下位置找到:soc soc “
请确保您的 EDS 文件和 SOC 文件彼此一致、以避免任何不匹配。

此致、
Pourya
尊敬的 Yashaswini:
我看到的主要问题是您正在根据 CT22 进行测试、而根据 SDK 09.02.00.24 的 EIP 数据表、您应该使用 CT21。
CT22 基于较新版本的 CIP 规范构建、该规范将纳入我们的 下一个版本。
请切换到使用 CT21 进行测试、 如果您遇到任何问题、请告诉我。
此致、
Pourya
你好 Pourya Eskandari ,
我希望您做得好。 我们已收到 ODVA 要求使用 CT22 进行评估的请求、我们已成功获得该版本的许可证。 随着客户评估的进行、我们迫切希望继续使用 SDK 的新版本、以便尽快适应 CT22。 请您提供有关该新版本发布多久的估计信息? 同时、如果我们可以实施任何解决办法来保持工作进展、我们将非常感激。 感谢您对此事的帮助。
此致、
Yash Mehta.
尊敬的 Yash:
我们目前正在实施新的规范更新、以确保与 CT22 的兼容性。 这些变更将纳入我们计划于 2026 年第一季度发布的下一个版本中。
此发行时间表与 ODVA 规范强制变更列表中指定的日期一致
此致、
Pourya
你好 Pourya
e2e.ti.com/.../CT21_5F00_Hon2018_5F00_EIP_5F00_CC.log、


尊敬的 Yashaswini:
我对迟来的答复感到抱歉;我在办公室外。
您能否提供您运行的测试的 Wireshark 捕获? 理想情况下、重复测试、并将 CT 日志和 Wireshark 迹线上传为 ZIP 文件。
从 CT 日志中、更改 IP 地址的命令似乎未成功。 为了进一步调查列表身份问题、我需要查看 Wireshark 日志以确定是否正确处理了请求。
您还能否确认是否正确处理了重置请求?
此致、
Pourya
你好 Pourya
我已附上相关文件的 zip 文件
谢谢你
我已经重新测试了以下是所附的文件
尊敬的 Yashaswini:
以下是我的意见:
1) 在 STC (.SOC) 文件中、MAC 地址与被测试的设备不匹配、这将导致 LLDP 和 TCP/IP 对象测试中出现错误。 

2) 关于我之前关于重置请求的查询,我注意到 2 类和 1 类重置请求都被跳过。 您能否解释一下为什么会发生这种情况、并确认是否正确处理了复位请求?
您是否还可以确认是否正确处理了重置请求?

3) 您的.SOC 文件似乎被错误地配置为用于 IO 连接、因为设备拒绝了任何打开 IO 连接 (ForwardOpen) 的尝试、并且出现了“无效 O->T 大小“错误(扩展状态代码 0x127)。 请使用正确的 O->T 和 T->O IO 流大小更新您的 SOC 文件、以便与设备匹配。 
导致剩余错误的根本原因似乎是在运行 CT21 测试的 PC 上配置错误。 请按照 CT21 用户手册(可通过“帮助“>"参考“参考“>"用户“用户手册“访问)中的说明进行正确的 PC 网络配置。

此致、
Pourya
尊敬的 Pourya:
感谢您的建议—他们帮助我们大大减少了错误。 但是、我们仍有一些问题需要澄清:
1 类和 2 类复位测试:
我们不会有意跳过这些测试、但该工具仍会报告跳过了这些测试。 我们不确定为什么会出现这种情况。
DUT 响应时间误差:
我们看到多个错误、表明 DUT 需要超过 300ms 的响应时间。 您能帮助我们了解导致这种情况的原因吗?
TCP/IP 测试问题:
在我们的应用程序中、IP 地址的最后一个八位字节是使用旋转开关设置的。 我们怀疑这可能会阻止 IP 地址在测试过程中更改。 这可能是根本原因吗?
连接管理器测试:
我们尝试了数据大小的多种组合、但仍然出现错误。 是否有办法确定测试预期的准确 O→T 和 T→O 尺寸?
尊敬的 Yashaswini:
1) 复位问题: 是否观察到设备重新启动? 您是否可以在测试期间捕获 UART 日志?
如果没有、您是否有任何可观察的方法(LED 等)来查看器件是否实际重新启动?
如果这也不可行、您需要调试应用并放置一个断点、查看是否 调用了 CMN_OS_RESET。 
2) DUT 响应时间: 您是将 DUT 直接连接到 Test-PC LAN 端口、还是涉及 USB 以太网适配器? 如果您正在使用任何可能导致意外延迟的 USB 以太网适配器。
除此之外、另一个问题是您在另一个 E2E 请求单中提到的问题、即您添加到主要任务的延迟。
3) TCP/IP 测试问题: 是的、如果代码的另一部分覆盖了 IP 地址设置、则可能是根本原因。
4) 连接管理器测试: 您必须已经知道 O->T 和 T->O 有效负载大小、PLC 还能如何与您的设备通信并建立 IO 连接? 只需使用与 EDS 文件中使用的负载大小完全相同的有效负载。 它是生产和消耗装配体的大小。
此致、
Pourya
你好 Pourya
1) 重置问题
我已经验证了CMN_OS_reset我们的应用程序中正在调用它。 我附上了 UART 日志以供您参考。
2) DUT 响应时间
DUT 直接连接到测试 PC。
目前、我无法访问 CT21 软件日志文件。 现在、我附上了完整的 UART 日志(从测试开始到结束)、Wireshark 捕获以及一些屏幕截图。
你好 Pourya Eskandari ,
以下是 Yashaswini S D 上次从她的测试中提供给我的日志。 这包括一致性测试日志和 Wireshark 数据。 如果您需要任何其他信息、请告诉我。
谢谢、
Yash Mehta.
尊敬的 Yash:
基于日志分析:
1) 列表标识的时间不正确 :这似乎是由主任务的延迟造成的,正如我们之前讨论过的。
2) TCP/IP 对象故障 :这是因为您的应用程序覆盖了从网络接收到的 IP 配置。 例如、当测试工具尝试将 IP 地址更改为 192.168.1.11 时、该设置将无法应用。
1) 任务独立性: 确保 DAC 任务独立于主任务运行。 如果这些任务之间需要进行数据交换、则应实施适当的任务间通信机制(例如信号或队列)来管理安全的数据传输。 DAC 任务的任务优先级是多少?
实施适当的状态机、何时以及如何应用旋转开关设置以及何时从网络发出请求。 
如果您希望设备的 TCP/IP 属性完全由旋转开关控制、并且不能从网络中进行修改、这在技术上是可行的。 但是、此功能需要 EtherNet/IP 协议栈的自定义补丁、因为它未包含在标准 SDK 提供的标准 EIP 实现中。
此致、
Pourya
你(们)好
感谢您发送编修。感谢您发送编修。我们会重新检视您的建议
我们独立于主任务运行 DAC 任务、但仍收到 DUT 的响应延迟、这可能是什么原因?e2e.ti.com/.../ODVATCP.zip
我附加了错误日志以供您参考
尊敬的 Yashaswini:
您的附加文件中未上载 Wireshark 日志、根据日志本身、我无法提供问题的最终诊断。 为了更好地帮助您、我需要:
1) Wireshark 捕获: 如果可用、请共享此测试的 Wireshark 日志。 如果没有、请考虑重新运行测试、同时使用 Wireshark 捕获网络流量。
2) 任务调度信息: 该问题可能与 FreeRTOS 任务调度有关。 具体来说、EtherNet/IP 内部任务可能没有收到足够的处理时间。
一种可能值得研究的情况是任务优先级配置。 如果您的 DAC 任务被分配了一个非常高的优先级并且不产生控制(通过 TaskP_yield ,等待信号运行或类似的调用),它可能会垄断 CPU 时间。 这将阻止优先级较低的任务(包括关键 EtherNet/IP 任务)正确执行。
请告诉我:
1) 分配给您的 DAC 任务的优先级是多少?
2) 您的 DAC 实现是否包含适当的屈服点,或者您是否实施某种类型的信号机制来等待事件,然后执行?
3) 您是否监控了任务执行时间? 如果您的项目基于 TI 示例、最简单的方法是 启用 WebServer 并监控执行时间。 请提供运行一致性测试时的 WebServer 屏幕截图。
这种排班不平衡可以解释您遇到的症状。 其他诊断信息有助于确认这一假设或确定替代原因。
此致、
Pourya
你好 Pourya
我们重复了 ODVA 测试相同的卡与相同的固件,但它显示了不同的结果,我已附加的文件供您参考.为什么这种情况?
对于 LLDP 测试、即使 MAC 地址已更改且 PC 中的设置也正确、我仍会收到错误
e2e.ti.com/.../ODVA-_2800_2_2900_.zipe2e.ti.com/.../ODVA124.zip
1) 我检查了 DAC 优先级、它是 7、以太网任务是 8。
2) 是—我们当前的 DAC 路径是信号驱动的,而不是紧密的轮询循环。
3) 我更改 CPU_LOAD_MONITOR =1 时遇到以下错误
#10099-D 程序无法放入可用的存储器中、或者段包含一个调用点、该调用点需要无法为该段生成蹦床函数。 对于段“Group_8"大小“大小 0x9407、存在对齐的放置失败。 可用存储器范围:
您好 Yashaswini、
以下是我对您提供的文件的评论:
关于“ODVA124.zip"</s>“
(请在以后的上传中使用更多描述性文件名以阐明其内容):
该测试用例显示了重大误差。 日志揭示了通信问题的症状(可能是网络接口配置错误,数据包丢失,RGMII PHY 接口错误等)、但它们不能提供明确的根本原因指示。
你好 Pourya
在 LLDP 上,即使在 soc 文件中更改 MAC 地址后,我仍然有相同的问题
我已附加 Wireshark 捕获和错误。 我们已将 LLDP 相邻设备增加到 60 个、是否会导致任何问题? 独立测试显示的误差与一致性测试不同? 例如、TCP/IP 测试在独立测试时不会出现错误、但当通过一致性测试时会产生错误。
尊敬的 Yashaswini:
它看起来一致性测试报告和 Wireshark 日志不匹配、因为一致性测试中提到的数据包不存在于 Wireshark 日志中。

此致、
Pourya