[参考译文] PROCESSOR-SDK-AM64X：从 MCU Plus SDK 移植快速启动示例时无法建立链路

尊敬的 Teja：

  我们正在使用不带 I2C EEPROM 的定制板、因此我们必须在 SysConfig 中使用自定义电路板配置、并使用 enet_custom_board_config.c 来提供 Enet lib 所需的基本功能。 然后根据你的建议,我认为我必须将  isStraped 和 skip ExtendedCfg 从 false 更改为 true。 然后再次运行应用程序。

｛/*“CPSW3G “*/
.enetType = ENET_CPSW_3G、
.instId = 0u、
.macPort = ENET_MAC_PORT_1、
.mii =｛ENET_MAC_LAYER_GMII、ENET_MAC_SUBLAYER_REDULED｝、
.phyCfg =
｛
.phyAddr = 0、
.isStraped = true、
.skipExtendedCfg = true、
.extendedCfg =&gEnetCpbBoard_dp83867PhyCfg、
.extendedCfgSize = sizeof (gEnetCpbBoard_dp83867PhyCfg)、
}、
.flags = 0u、
}、

现在 CPSW 可以知道链路已接通、但接收和发送看起来无法正常工作、并在等待接收 DMA 时卡住。 这是日志。 看起来不是真正的成功。

=========================
CPSW 快速启动
=========================
启用时钟！
EnetAppUtils_reduceCoreMacAllocation：将 CoreID:1 的 Mac 地址分配从 4 减少到 2
mdio_open：启用 mdio Manual_Mode
打开 MAC 端口 1
EnetPhy_bindDriver: PHY 0: OUI:080028 型号:23 Ver:01 <->'D.P83867':确定
PHY 0 处于活动状态
initQs() txFreePktInfoQ 使用 2 个 pkts 初始化
cpsw-3G:正在等待链路接通...
Cpsw_handleLinkUp：端口 1：链路接通：1Gbps 全双工
MAC 端口 1：链路接通

在更改配置 strap 配置之前、我尝试将等待链路时间从 3000us 更改为 1s。  

while（gEnetApp.run &&！链接）
｛
EnetApp_phyStateHandler()；
Enet_IOCTL_SET_INOUT_args (&PRM、&macPort、&linked)；

Enet_IOCTL (gEnetApp.henet、gEnetApp.CoreID、ENET_PER_IOCTL_IS_PORT_LINK_UP、&PRMS、STATUS)；
IF (STATUS ！= ENET_Sok)
｛
EnetAppUtils_print（“%s"：“：无法获取端口%u 链接状态：%d\r\n“、
gEnetApp.name、ENET_MACPORT_ID (macPort)、STATUS)；
已链接= false；
休息；
}

if（！linked）
｛
// ClockP_usleep (3000U)；
ClockP_SLEEP (1U)；
}
暴露
｛
profile_time (ClockP_getTimeUssec ())；
}
}

示例可以成功运行。 这是日志。

=========================
CPSW 快速启动
=========================
启用时钟！
EnetAppUtils_reduceCoreMacAllocation：将 CoreID:1 的 Mac 地址分配从 4 减少到 2
mdio_open：启用 mdio Manual_Mode
打开 MAC 端口 1
EnetPhy_bindDriver: PHY 0: OUI:080028 型号:23 Ver:01 <->'D.P83867':确定
PHY 0 处于活动状态
initQs() txFreePktInfoQ 使用 2 个 pkts 初始化
cpsw-3G:正在等待链路接通...
Cpsw_handleLinkUp：端口 1：链路接通：1Gbps 全双工
MAC 端口 1：链路接通
=================================================
快速启动性能分析日志（以微秒 (us) 为单位）
=================================================
申请开始时间:4548
Enet-LLD 初始化完成时间:52549
两个端口连接时间：6076747
从端口 1 发出的第一个数据包的时间：6076792
在端口 2 上接收到第一个数据包的时间：0
应用程序正在终止...
正在终止应用程序
Cpsw_handleLinkDown：端口 1：链路断开

尊敬的 Teja：

   感谢您的快速答复！ 实际上、我们正尝试在 r5fss0 上运行轻量级 EtherCAT 主站堆栈、并使用 CPSW 或 ICSSG 作为网络接口。 因此、我们对网络接口的基本要求是：

1.无 RTOS

2、能够直接、高效、快速地访问网络外围设备。 所以我们不想使用 LWIP 或其他中间件。 设置用于直接访问 DMA 指针和缓冲存储器。

您是否有我们可以遵循的一些更好的起点或基本示例？

顺便说一下、在快速启动示例中、我更改了等待链路接通的延迟时间之后。 我能够建立链路并发送软件包。 但我发现了另一个问题,大约 194 次发送包裹后,任务看起来挂起,停止发送任何东西。 很奇怪、我怀疑一些后台任务（可能是 phy 监控任务）在 DMA 需要的一些资源上存在一些死锁。 但 SDK 太大了、文件夹和文件以一种非常复杂的方式分组、我不能深入挖掘。 请帮助！ 谢谢！

这是我的代码。

e2e.ti.com/.../hsn_5F00_r5fss0_2D00_0_5F00_nortos_5F00_ti_2D00_arm_2D00_clang.zip

您好、Brian、

当您从应用程序发送数据包时、您是否还能观察到数据包也发送到线路上？ 除了上面提供的文档中的建议更改、以及等待链路建立延迟的更改之外、是否对应用进行了任何修改？ 如果是、请分享详细信息、以便我们更好地理解问题并尝试重现问题。

此致、
Teja。

尊敬的 Teja：

好的。 让我更详细地介绍测试：

硬件：基于 AM6442 的定制电路板、不含 I2C EEPROM 来存储 MAC、CPSW RGMII 端口 1 连接到 DP83867。 不使用端口 2。

软件：CCS 12.8-1、 MCU_PLUS_SDK_am64x_10_01_00_32

目标：在没有 RTOS 和 LWIP 的情况下构建裸机 CPSW 发送和接收驱动程序、系统应具有最小的延迟、抖动和复制。 它意味着用作 EtherCAT 主站协议栈的基础。

构建和测试步骤：

步骤 1：将 C：\ti\mcu_plus_sdk_am64x_10_01_00_32\examples\empty\am64x-evm\r5fss0-0_nortos 导入到工作区

步骤 2：启用 CPSW、将 RTOS 型号更改为“无 RTOS“、将 RX 和 TX DMA 通道编号更改为 16。 将大小为 1536 的软件包池配置编号设置为 32。 禁用 MAC2 端口。 启用定制电路板。 正如我记得的那样、我只更改这些内容并将其他项保留为默认值。 详情请参阅我上次回复中的 zip 文件。

步骤 3： 从 C：\ti\mcu_plus_sdk_am64x_10_01_00_32\source\networking\enet\core\examples\enet_layer2_multi_channel\am64x-evm\r5fss0-0_freeRTOS 复制自定义电路板配置文件 enet_custom_board_config.c。 然后更改函数 EnetBoard_getMacAddrList 以禁用从 EEPROM 获取 MAC（因为我们的电路板没有 EEPROM）到硬代码 MAC 的操作。

步骤 4：从 C：\ti\mcu_plus_sdk_am64x_10_01_00_32\source\networking\enet\core\examples\enet_cpsw_fast_startup 复制应用代码

步骤 5：在 EnetApp_waitForLinkUp 函数中获取链路位失败时、将 ClockP_usleep 睡眠时间更改为睡眠 100ms。

步骤 6：然后我们进行测试以确认应用程序确实可以建立链路。

步骤 7：我们禁用原始 while (true) 周期、这意味着回显它接收的帧。  

第 8 步:我们做了一个新的 while (true)  

while(1)
{
    EnetQueue_initQ(&TxPktQueue);
    EnetApp_preparePktQ(&TxPktQueue);
    EnetApp_sendPktQ(&TxPktQueue);
    ClockP_usleep(200000U);
}

步骤 9：电路板已经准备好作为 SDK 手册从 OSPI 引导、固件已经初始化资源。 CPSW RJ45 连接到另一台运行 Wireshark 的 PC。 启动时、日志为：

DMSC Firmware Version 10.0.8--v10.00.08 (Fiery Fox)
DMSC Firmware revision 0xa
DMSC ABI revision 4.0

KPI_DATA: [BOOTLOADER_PROFILE] Boot Media       : NOR SPI FLASH
KPI_DATA: [BOOTLOADER_PROFILE] Boot Media Clock : 166.667 MHz
KPI_DATA: [BOOTLOADER_PROFILE] Boot Image Size  : 380 KB
KPI_DATA: [BOOTLOADER_PROFILE] Cores present    :
m4f0-0
r5f1-0
r5f1-1
a530-0
r5f0-0
r5f0-1
KPI_DATA: [BOOTLOADER PROFILE] SYSFW init                       :      11108us
KPI_DATA: [BOOTLOADER PROFILE] System_init                      :     363649us
KPI_DATA: [BOOTLOADER PROFILE] Drivers_open                     :       1673us
KPI_DATA: [BOOTLOADER PROFILE] Board_driversOpen                :     136049us
KPI_DATA: [BOOTLOADER PROFILE] Sciclient Get Version            :       9988us
KPI_DATA: [BOOTLOADER PROFILE] CPU Load                         :      41991us
KPI_DATA: [BOOTLOADER PROFILE] SBL End                          :       3268us
KPI_DATA: [BOOTLOADER_PROFILE] SBL Total Time Taken             :     567730us

Image loading done, switching to application ...
[m4f0-0]     0.097200s : [IPC RPMSG ECHO] Remote Core waiting for messages from                                                                             main core ... !!!
[r5f0-1]     0.002149s : [IPC RPMSG ECHO] Remote Core waiting for messages from                                                                             main core ... !!!
[r5f1-0]     0.096238s : [IPC RPMSG ECHO] Remote Core waiting for messages from                                                                             main core ... !!!
[r5f1-1]     0.096252s : [IPC RPMSG ECHO] Remote Core waiting for messages from                                                                             main core ... !!!
[a530-0]     0.012084s : [IPC RPMSG ECHO] Remote Core waiting for messages from                                                                             main core ... !!!
[IPC RPMSG ECHO] Message exchange started by main core !!!
[IPC RPMSG ECHO] All echoed messages received by main core from 5 remote cores !                                                                            !!
[IPC RPMSG ECHO] Messages sent to each core = 100000
[IPC RPMSG ECHO] Number of remote cores = 5
[IPC RPMSG ECHO] Total execution time = 5065733 usecs
[IPC RPMSG ECHO] One way message latency = 5065 nsec

步骤 10：通过 XDS200 将该应用程序加载到 r5fss0-0、然后运行、日志为：

All tests have passed!!
Mdio_open: MDIO Manual_Mode enabled
EnetPhy_bindDriver: PHY 0: OUI:080028 Model:23 Ver:01 <-> 'DP83867' : OK
Cpsw_handleLinkUp: Port 1: Link up: 1-Gbps Full-Duplex

在 Wireshark 上、我们可以看到电路板大约每 200ms 就会发出板播帧。 但发送作业将在 16 个周期后冻结。  

第 10 步：点击暂停调试按钮、我们可以看到应用发出断言  

指向此处

似乎未能 DEQ 一个免费的 txFreePktInfoQ 导致发送冻结。

您能告诉我如何在没有数字限制的情况下持续发送帧吗？ 谢谢！

您好、Brian、

如果应用每次在 16 个数据包之后卡住、则可能与 数据包处理流有关、其中应用程序无法让 freeTxBuffers 将数据包发送出去、这就是它在上述 DEQ 函数中失败的原因。 您能否检查您正在使用的传输任务是否遵循与开箱即用示例相同的顺序？  请确保包括 EnetDma_retrieveTxPktQ()；调用以获取可用的 Tx 数据包返回应用程序以再次发送新数据包。

此致、
Teja。