[参考译文] TMDS243EVM：PROFINET 示例卡在 PNIO_DEVICE_OPEN 中

简要更新：

在第三方 SoM 上、我们在从"EDD "任务调用的 EDDP_GlbFatalError 中失败。 UART 上未显示错误消息。 如果您对如何调试该问题有一些建议、也会很有帮助。

此致、

Dominic

我们将在下周排定优先级；我发现此主题与之类似： (+) AM2432：Profinet -基于 Arm 的微控制器论坛-基于 Arm 的微控制器- TI E2E 支持论坛中的非循环数据问题 、他们在 调整 MPU 和示例链接器配置方面取得了一定的成功。

我们修复了适应第三方 SoM 的代码中的问题、现在我们卡在与 AM24x EVM 相同的位置(卡在 PNIO_DEVICE_OPEN 轮询 pnpb_get_state 中)。

我阅读此其他线程的方式、似乎一个更改修复了一个主板上的问题、导致了另一个主板上的问题：

Unknown 说：

如果我更正了此问题、堆栈在一个电路板上可以正常工作、但使用另一个电路板(可能具有不同的版本)时仍然无法工作、为了使其工作、我必须复制 MPU 和连接器的演示配置。

不确定它有多大帮助。

从链接器脚本/存储器区域以及 MPU 设置来看、要了解不同存储器区域的使用方式是相当困难的。 MPU 段的名称似乎与它们的用法不匹配、并且存在几个未使用的链接器区域。

是否有任何文档介绍了 Profinet 栈需要什么样的存储器区域？

一旦我们可以在第三方 SoM 上安装堆栈并运行、我们打算转为采用 Linux (A53)+ FreeRTOS (R5f)设置、在该设置中、堆栈预计将随 Linux 一起在 R5f 上运行。 为此、最好了解栈的要求、而不是盲目调整可能使用或可能不使用的现有区域。

此致、

Dominic

卡米尔·阿尔库里 将在明天开始讨论这个问题

您好、Dominic：

我们将尝试查看我们是否能够在这里重现该问题。 您是否会共享您的链接器脚本和 syscfg 文件？

谢谢。
此致、
Kamil

您好、Kamil：

在 AM24x EVM 上、我们将使用来自工业通信 SDK 09.02.00.15示例的链接器脚本和 syscfg 文件原样。

链接器脚本实际上是从 syscfg 文件生成的。 我已附上 syscfg 文件供您参考：

e2e.ti.com/.../1016.example.zip

请注意、我们很可能会遇到两个不同的问题：

• 软件在3个 AM24x EVM 中的1个上失败
  • 故障电路板被修改为使用外部 PCIe 参考时钟、而不是板载时钟发生器
  • 其他工业通信示例在该电路板上也可以正常工作、例如 EtherCAT 和 EtherNet/IP 示例
• 第三方 AM64x SoM 上的软件发生故障
  • 我们修改了示例应用程序以匹配第三方 SoM、主要包括：
    • 使用 ICSSG0而非 ICSSG1
    • 使用 DP83867 PHY 而非 DP83869
    • 我们为 NVM 使用 EEPROM 而不是闪存(在 pn_app_iod_bsp.h 中进行了更改)
  • 检测到 PHY 并且将其配置为运行 MII

在两种失败的情况下、应用程序都卡在 PNIO_DEVICE_OPEN 中。

此致、

Dominic

您好、Dominic：

PNIO_DEVICE_OPEN()是许多线程开始工作的地方、因此在这一点很难判断。

1.根据共享的 SysConfig 文件、我看到您使用的是默认配置(ICSSG1搭配 DP83869)。 您能进一步说明这一点吗？  
为了重现此问题、我需要 SysConfig 文件来反映您在这方面的所有更改。

2.检测到 PHY 处于活动状态、但您是否检测到  通过它们发送 到网络(Wireshark 等)的任何消息？ 您是否可以尝试从应用程序生成任何随机 IP 流量以验证该流量？ (在 调用 PN_APP_IOD_STARTUP 之前)

3.切换到 EEPROM 而不是闪存应该不会引起任何问题。

4.出于测试目的、我为 AM243x_EVM 共享了一个.out 文件。 您是否可以尝试将其加载到故障电路板上并告诉我结果？
e2e.ti.com/.../profinetio_5F00_device_5F00_am243x_5F00_evm_5F00_r5f_5F00_freertos_5F00_mii_5F00_2_5F00_Release.out
谢谢。
此致、
Kamil  

您好、Kamil：

来自 AM24x EVM。 在 AM24x EVM 上、我们将使用工业通信 SDK 中的示例、不做任何更改。

对于第三方 SoM、我们有一些更改、尤其是上面提到的更改(ICSSG0、DP83867、EEPROM、而非闪存)。 我还附上了它的 SysConfig 文件：

e2e.ti.com/.../example_5F00_3rdparty_5F00_som.zip

Unknown 说：

2.    是否检测到 PHY 活动、但您是否检测到通过它们发送到网络(Wireshark 等)的任何消息？ 您是否可以尝试从应用程序生成任何随机 IP 流量以验证该流量？ (在 调用 PN_APP_IOD_STARTUP 之前)

在显示问题的 AM24x EVM 上(卡在 PNIO_DEVICE_OPEN 中)、调用 PN_API_IOD_STARTUP 后没有链接。 对电路板进行下电上电后、首次存在1Gbit/s 的链路、直到我调用 PN_API_IOD_STARTUP 为止、此时链路会丢失。 如果我然后只是"系统重置"板(我通常这样做)、则根本没有链接。

在正常工作的 AM24x EVM 上、下电上电后首次存在1Gbit/s 链路、直到调用 PN_API_IOD_STARTUP、此时链路短暂断开并以100Mbit/s 的速度恢复

在工作中的 AM24x EVM 上、即使未连接以太网电缆、也会返回对 PN_API_IOD_STARTUP 的调用、因此我假设(缺失)以太网链路不是 PN_API_IOD_STARTUP 的阻塞点。

我必须让我的同事验证第三方 SoM 上的链路状态。

Unknown 说：

3. 切换到 EEPROM 而不是闪存不会导致任何问题。

这是我的预期、感谢您的确认。 请注意、我们仅在第三方 SoM 上切换到了 EEPROM。 在 AM24x EVM 上、我们使用闪存。

Unknown 说：

4. 出于测试目的、我为 AM243x_EVM 共享了一个.out 文件。 您是否可以尝试将其加载到故障电路板上并告诉我结果？
profinetio_device_am243x_evm_r5f_freertos_MII_2_Release.out[/报价]

该二进制文件在故障 EVM 上也无法正常工作。

(null bootloader output ...)
INFO: Bootloader_runSelfCpu:217: All done, reseting self ...

Restore remanent memory indicated.
Using user-defined submodule configuration (not from remanent memory).
Restore remanent memory indicated.
Restore remanent memory indicated.
Restore remanent memory indicated.
Restore remanent memory indicated.
Restore remanent memory indicated.
[APP] INFO: Initializing PRU instance ...
                                         DP83869 detected
DP83869 detected
Phy 15 : Disable RGMII mode
Phy 15 : Disable GBit ANEG
Phy 3 : Disable RGMII mode
Phy 3 : Disable GBit ANEG

二进制文件后、我没有找到链接、仍然卡在 PNIO_DEVICE_OPEN 中。 在工作和非工作情况下、UART 上的输出基本相同。 以上输出来自非工作电路板上的二进制文件。

此致、

Dominic

您好、Kamil：

我花了更多的时间来研究正在工作和正在非工作的 AM24x EVM 上的以太网链路之间的区别。

我可以看到、Profinet 协议栈代码在两个电路板上将 PHY 都置于断电模式、但在不工作的电路板上 PHY 永远不会再次通电。

我还可以看到、该代码在工作板上调用 CUST_PHY_DP83869_setLinkConfig、但从不在工作板上调用该函数。

不知道这只是一个更早的阻塞点的症状、或表明我们在单个电路板上遇到问题的原因。

我是否可以检查任何其他点、以便了解初始化在不工作的电路板上可以到达多远？

此致、

Dominic

您好、Kamil：

您有没有为我们提供的更新信息？

这一做法目前正阻碍着我们的发展、而且由于采用二进制 Profinet 协议栈、我们进行调试的能力也受到极大的限制。

如果我们可以首先集中精力解决 EVM 问题、然后查看第三方 SoM、就会很好。

此致、

Dominic

您好、Dominic：

感谢您的答复和耐心。
我们正在与另一个团队一起执行其他一些任务来解决此问题。 我很快就会给您回复。
我还将尝试检查我们是否能为您提供调试功能、以便您也能为我们提供帮助。

此致、
Kamil

您好、Dominic：

Unknown 说：

故障电路板修改为使用外部 PCIe 参考时钟而非板载时钟发生器

在 AM243 EVM 上、您是否仅在开箱即用应用程序上进行了此更改？
您是否已尝试 使用板载时钟发生器并检查同一电路板上是否仍然出现启动问题？  

此致、
Laxman

您好、Laxman、

这是一项硬件修改(请参阅 https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/10_00_00_20/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_PCIE_ENUMERATE_EP.html)、需要移除多个0 Ω 电阻器并添加其他电阻器。 除非您有令人信服的说明为什么会影响 Profinet 示例、否则我不希望在此电路板上混乱。

应用程序(软件)完全未修改。

此致、

Dominic

小更新：

我已经使用具有相同硬件修改的 AM64x EVM 进行了测试、这个电路板未显示问题。

->我怀疑硬件修改是否可针对此问题进行

此致、

Dominic

您好、Dominic：

您很快会收到一封电子邮件、其中包含要测试的二进制文件。

谢谢你。
此致、
Kamil

您好、Dominic：

我们明天将向您发送二进制文件。 目前我们需要验证一些内容... 您是否尝试过复位 NVM？ 如果没有、请执行以下操作：

1.将 main.c 替换为相应的附加文件
2.将 pn_app_iod_bsp.c 替换为随附的相应文件
3.重新构建并运行程序一次、然后将 UART 日志发送给我。
4.加载上一个程序(挂起的程序)并将 UART 日志发送给我。

谢谢。
此致、
Kamile2e.ti.com/.../7713.main.ce2e.ti.com/.../pn_5F00_app_5F00_iod_5F00_bsp.c

您好、Kamil：

由于缺少一些定义、该代码不会按原样构建：

SYNC_OUT0
GPIO_OUT_HW_SIGNAL_BASE_ADDR
GPIO_OUT_HW_SIGNAL_PIN
GPIO_OUT_HW_SIGNAL_DIR

尝试修复这些问题是否合理、或者您是否有更接近09.02.00.15的其他更改版本？

此致、

Dominic

您好、Dominic：

啊、是的。 这些定义属于比您拥有的版本更新的版本、但它们都是无关的、因此可以删除与它们相关的任何代码。
我尝试在我这边做(附加了新文件)、但你也可以自己做。

谢谢。
此致、
Kamil

e2e.ti.com/.../6457.main.ce2e.ti.com/.../6457.pn_5F00_app_5F00_iod_5F00_bsp.c

您好、Kamil：

我已注释掉了所有对缺少的#defines 的引用。

已构建并运行的应用程序具有以下输出：

DEBUG: NVM is cleared.

之后、我运行了您之前共享的应用程序：

Unknown 说：

4. 出于测试目的、我为 AM243x_EVM 共享了一个.out 文件。 您是否会尝试将其加载到故障电路板上并告诉我结果？

输出如下：

Restore remanent memory indicated.
Using user-defined submodule configuration (not from remanent memory).
Restore remanent memory indicated.
Restore remanent memory indicated.
Restore remanent memory indicated.
Restore remanent memory indicated.
Restore remanent memory indicated.
[APP] INFO: Initializing PRU instance ...
                                         DP83869 detected
DP83869 detected
Phy 15 : Disable RGMII mode
Phy 15 : Disable GBit ANEG
Phy 3 : Disable RGMII mode
Phy 3 : Disable GBit ANEG

之后、我遇到了与之前相同的问题(卡在 PNIO_DEVICE_OPEN 轮询 pnpb_get_state 中)。

此致、

Dominic

您好、Dominic：

请检查您的电子邮件。 另外还发送了二进制文件进行测试。

谢谢。
此致、
Kamil

您好、Dominic：

感谢您在通过电子邮件调试问题方面的合作。 第一个问题("3个 AM24x EVM 中有1个发生软件故障")是由分配给故障电路板的无效 MAC 地址导致 堆栈无法继续启动引起的。 此问题可通过修复 MAC 地址来解决。

现在、需要对第二个问题("第三方 AM64x SoM 上的软件发生故障")进行更新。

谢谢。
此致、
Kamil

您好、Kamil：

可能还需要为以后的读者提供一些其他信息：

Profinet 示例应用程序从 EVM 上的电路板 ID EEPROM 读取 MAC 地址。 在非工作电路板上、电路板 ID EEPROM 的 MAC 地址全为零、但其他情况下"正常"、例如、它在标头中具有有效的幻数、并且包含电路板名称 AM243-EVM。 目前还不清楚为什么这个特定的开发板没有在开发板 ID EEPROM 中包含一个有效的 MAC 地址、例如是否采用了这种方式、或者是否在以后的某个时候被擦除。

对于、我们已修复了这一问题、方法是手动初始化 APP_HW_BOARD_INFO_DATA_g 的"MAC"字段、而不是从 EEPROM 读取该结构。

在第三方 AM64x SoM 上、我们遇到了相同的问题、在我们的最终解决一些其他小问题之后、现在也会将 SoM 检测为 Profinet 器件。

此致、

Dominic