PROCESSOR-SDK-AM64X: Not able to get link up when porting the fast startup example from MCU Plus SDK

Hi Teja,

    We are using our customized board without I2C EEPROM, So we have to use customize board config in sysconfig and using the enet_custom_board_config.c to provide the essential functions that the enet lib need. Then according your suggest, I think I have to change the isStrapped and skipExtendedCfg from false to true. Then run the application again.

{ /* "CPSW3G" */
.enetType = ENET_CPSW_3G,
.instId = 0U,
.macPort = ENET_MAC_PORT_1,
.mii = { ENET_MAC_LAYER_GMII, ENET_MAC_SUBLAYER_REDUCED },
.phyCfg =
{
.phyAddr = 0,
.isStrapped = true,
.skipExtendedCfg = true,
.extendedCfg = &gEnetCpbBoard_dp83867PhyCfg,
.extendedCfgSize = sizeof(gEnetCpbBoard_dp83867PhyCfg),
},
.flags = 0U,
},

Now the CPSW can aware of link up, But the receive and transmit looks like not functional and got stuck when waiting for the receive DMA. Here is the Log. Looks like it is not really success.

==========================
CPSW Fast Startup
==========================
Enabling clocks!
EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 2
Mdio_open: MDIO Manual_Mode enabled
Open MAC port 1
EnetPhy_bindDriver: PHY 0: OUI:080028 Model:23 Ver:01 <-> 'DP83867' : OK
PHY 0 is alive
initQs() txFreePktInfoQ initialized with 2 pkts
cpsw-3g: Waiting for link up...
Cpsw_handleLinkUp: Port 1: Link up: 1-Gbps Full-Duplex
MAC Port 1: link up

Before I changge the config of strapped, I tried to change the wait linkup time from 3000us to 1s. 

while (gEnetApp.run && !linked)
{
EnetApp_phyStateHandler();
ENET_IOCTL_SET_INOUT_ARGS(&prms, &macPort, &linked);

ENET_IOCTL(gEnetApp.hEnet, gEnetApp.coreId, ENET_PER_IOCTL_IS_PORT_LINK_UP, &prms, status);
if (status != ENET_SOK)
{
EnetAppUtils_print("%s: Failed to get port %u link status: %d\r\n",
gEnetApp.name, ENET_MACPORT_ID(macPort), status);
linked = false;
break;
}

if (!linked)
{
// ClockP_usleep(3000U);
ClockP_sleep(1U);
}
else
{
PROFILE_TIME(ClockP_getTimeUsec());
}
}

The example can run successfully. Here is the Log.

==========================
CPSW Fast Startup
==========================
Enabling clocks!
EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 2
Mdio_open: MDIO Manual_Mode enabled
Open MAC port 1
EnetPhy_bindDriver: PHY 0: OUI:080028 Model:23 Ver:01 <-> 'DP83867' : OK
PHY 0 is alive
initQs() txFreePktInfoQ initialized with 2 pkts
cpsw-3g: Waiting for link up...
Cpsw_handleLinkUp: Port 1: Link up: 1-Gbps Full-Duplex
MAC Port 1: link up
=====================================================
Fast Startup Profiling logs in Microseconds(us)
=====================================================
Application start time: 4548
Enet-lld initialisation done time : 52549
Both ports linked up time: 6076747
Time for First packet sent out from Port 1: 6076792
Time for First packet received on Port 2: 0
Application Terminating...
Terminating App
Cpsw_handleLinkDown: Port 1: Link down

Hi Teja,

     Thank you for your quick reply! Actrually, we are trying to run a light weight EtherCAT master stack on r5fss0 and use CPSW or ICSSG as the network interface. So our basic requirement for network interface is:

1. no rtos

2. possible to access to network peripheral directly and effeciently, fast. So we dont want to use LWIP or other midware. Bettter to access DMA pointer and buffer memory directly.

Do you have some better start point or basic example that we can follow?

by the way, After I change the delay time when waiting for link up in the fast startup example. I am able to link up and send package. But I found another problem, after about 194 times of sending package, the task looks hang up and stop sending anything. It's strange, I suspect some background tasks(maybe the phy monitor task) have some dead locking on some resources that the DMA need. But the SDK is too huge and the folders and files are grouped in a very complicated way, I can not dig more deep. Please help! Thank you!

Here is my code.

hsn_r5fss0-0_nortos_ti-arm-clang.zip

Hi Brian,

When you are sending the packet out from the application, are you able to observe the packets being sent out onto the wire as well? Are there any modifications done to the application apart from the suggested changes in the documentation provided above, and change in wait for link up delay? If yes, please share the details so that we can understand the issue better and try to reproduce the issue.

Regards,
Teja.

Hi Teja,

OK. Let me introduce the test more detail:

Hardware: Custom made board base on AM6442, without I2C EEPROM to store MAC, CPSW RGMII port 1 connected to DP83867. Port 2 is not used.

Software: CCS 12.8.1, mcu_plus_sdk_am64x_10_01_00_32

Target: build a bare matel CPSW send & receive driver without RTOS and LWIP, it should be minimum delay, jitter and copy inside. It mean to work as the basis of EtherCAT master stack.

Build & Test Steps:

Step 1: Import C:\ti\mcu_plus_sdk_am64x_10_01_00_32\examples\empty\am64x-evm\r5fss0-0_nortos to workspace

Step 2: Enable the CPSW, Change RTOS variant to "No RTOS", change both the RX and TX DMA Channel number to 16. Package pool config of size 1536 number to 32. Disable MAC2 port. Enable the custom board. As I remember I only change these things and keep others as default. Details please refer to the zip file in my last reply.

Step 3: copy the custom board config file enet_custom_board_config.c from C:\ti\mcu_plus_sdk_am64x_10_01_00_32\source\networking\enet\core\examples\enet_layer2_multi_channel\am64x-evm\r5fss0-0_freertos. Then change the function EnetBoard_getMacAddrList to disable getting the MAC from EEPROM(because our board doesn't have EEPROM) to a hardcode MAC.

Step 4: copy the app code from C:\ti\mcu_plus_sdk_am64x_10_01_00_32\source\networking\enet\core\examples\enet_cpsw_fast_startup

Step 5: Change the ClockP_usleep sleep time to sleep 100ms when failed to get the link bit in EnetApp_waitForLinkUp function.

Step 6: Then we made a test to confirm that the application can really get link up.

Step 7: We disable the original while(true) cycle which mean to echo back the frame it receive. 

Step 8: We made a new while(true) 

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

Step 9: The board is already prepared as the SDK manual to boot from OSPI and the firmware already initial the resources. The CPSW RJ45 is connected to another PC running wireshark. When boot up the log is:

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

Step 10: Load the app by XDS200 into r5fss0-0, and run, the log is:

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

And from the Wireshark, we can see the board sent out the boardcast frame as we want about every 200ms. But the sending job will freeze after 16 cycles. 

Step 10: Click the pause debug button and we can see that the applcation throw out a assert 

Point to here

looks like failed to deq a free txFreePktInfoQ result in the freeze in sending.

Could you help to tell me how to continuous sending out frames without the limit of numbers? Thank you!

Hi Brian,

If the application is getting stuck exactly after 16 packets every time, then it could be related to the packet handling flow, where application is not getting the freeTxBuffers to send the packets out, and this is why it would fail in the above mentioned deQ function. Can you please check if the transmit task that you are using follows the same sequence as the Out of box examples? Please make sure to include the EnetDma_retrieveTxPktQ(); call to fetch the free Tx packets back to the application to send new packets again.

Regards,
Teja.