LP-AM243: RGMII interface can not receive data from FPGA

hello

I also changed function enet_lwip_example function code

cpsw_regs.zipI also upload CPSW registers hex file from CCS, please check.

Hi cheng guo,

Thanks for your query.

I will check on this and get back to you.

I am assuming you are referring below documentation.

Custom Board Support

AM243x MCU+ SDK: Ethernet PHY Integration Guide

Regards

Ashwani

Hi Ashwani

Thanks for your reply.

Yes, we are using this SDK, but we are not integrating external phy, we connect RGMII1 to fpga, only RX pins are connected, because we only receive data from fpga and don't send anything to fpga. fpga send broadcast messages to RGMII1 RX interface, we can not receive the data. Please check, thanks very much.

Thanks cheng guo,

Looks like MAC2MAC connection.

1. Can you please raise schematic request review by TI HW expert?
2. In SW, you can try PHY MAC address = 0xFF in sysconfig.
3. Then, breakpoint in CpswMacPort_enablePort() should get hit.

Regards

Ashwani

Hi Ashwani

Yes, it's mac to mac connection.

We are not testing product pcb, we use lp-am243 board from TI flying wire connected to another seprate FPGA board. We need to test pass this test then we can design our schemetic.

In function enet_lwip_example in this sdk demo, broadcast mac address are already added.

int enet_lwip_example(void *args)
{
    Enet_Type enetType;
    uint32_t instId;
    int32_t status;

    Drivers_open();
    Board_driversOpen();

    DebugP_log("==========================\r\n");
    DebugP_log("      ENET LWIP App       \r\n");
    DebugP_log("==========================\r\n");

    EnetApp_getEnetInstInfo(CONFIG_ENET_CPSW0,
                            &enetType,
                            &instId);


    EnetAppUtils_enableClocks(enetType, instId);
    EnetApp_driverInit();
    status = EnetApp_driverOpen(enetType, instId);

    if (status != ENET_SOK)
    {
        EnetAppUtils_print("Failed to open ENET: %d\r\n", status);
    }

    EnetAppUtils_assert(status == ENET_SOK);
    {
        const uint8_t testBCastAddr[ENET_MAC_ADDR_LEN] =
        {
            0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
        };
        EnetApp_addMCastEntry(enetType,
                              instId,
                              EnetSoc_getCoreId(),
                              testBCastAddr,
                              CPSW_ALE_ALL_PORTS_MASK);
    }
#if (ENET_SYSCFG_ENABLE_EXTPHY == 1U)
    {
        uint8_t numMacPorts;
        uint32_t i;
        Enet_MacPort macPortList[ENET_SYSCFG_MAX_MAC_PORTS];

        EnetApp_getEnetInstMacInfo(enetType,
                                   instId,
                                   macPortList,
                                   &numMacPorts);

#if (ENET_SYSCFG_ENABLE_MDIO_MANUALMODE == 1U)
        EnetApp_createPhyRegisterPollingTask(1000, true, enetType, instId);
#else
        EnetApp_mdioLinkIntHandlerTask(enetType, instId);
        EnetApp_enableMdioStateMachine(enetType,
                                        instId,
                                        EnetSoc_getCoreId());
#endif

        portENTER_CRITICAL();
        uint32_t phyAddMask = 0;
        bool islinked = false;
#if 1
        /* port0 use RGMII1 interface, is connected to FPGA, do not poll */
        for (i = 1; i < ENETAPP_EXT_PHY_NUM_ENABLED_PORTS; i++)
        {
            EnetApp_waitForPhyAlive(enetType,
                                    instId,
                                    EnetSoc_getCoreId(),
                                    macPortList[i]);
            EnetApp_initExtPhy(enetType,
                               instId,
                               macPortList[i]);
            phyAddMask |= (1 << EnetApp_getExtPhyHandle(i)->phyCfg.phyAddr);
        }

        do {
            for (i = 1; i < ENETAPP_EXT_PHY_NUM_ENABLED_PORTS; i++)
            {
               islinked |= EnetExtPhy_WaitForLinkUp(EnetApp_getExtPhyHandle(i), ENETEXTPHY_TIMEOUT_MS);
            }
        } while (!islinked);
#endif
#if (ENET_SYSCFG_ENABLE_MDIO_MANUALMODE == 1U)
        EnetApp_enablePhyLinkPollingMask(phyAddMask);
#else
       (void)phyAddMask;
#endif
        portEXIT_CRITICAL();
    }
    #endif // #if (ENET_SYSCFG_ENABLE_EXTPHY == 1U)
    /* no stdio-buffering, please! */
    //setvbuf(stdout, NULL,_IONBF, 0);
    main_loop(NULL);

    return 0;
}

Can you help to check our cpsw configuration in the cpsw_regs.zip which contains all cpsw registers. Is our configuration not correct. Thanks.

Hi Ashwani

Thanks for you help. I manually changed register CPSW_PN_MAC_CONTROL_REG_k 0x08022330 with value 0x000200A1, then I can see mac tx register counters are not 0, but the rx values are still 0 for first mac port.

Our test suit has changed, now we just connect our tx lines of RGMII1 to rx lines of RGMII1, we want to test if we can receive frames when mac port send to itself. Currently we still got nothing in rx. We will check our hardware signals later.

cheng guo said:

we use lp-am243 board from TI flying wire connected to another seprate FPGA board.

Thanks for info.

cheng guo said:

I manually changed register CPSW_PN_MAC_CONTROL_REG_k 0x08022330 with value 0x000200A1, then I can see mac tx register counters are not 0

Good to hear that..

cheng guo said:

Can you help to check our cpsw configuration in the cpsw_regs.zip which contains all cpsw registers. Is our configuration not correct.

I will check and get bacj to you.

Regards

Ashwani

nok2.zipHi nok2.zip is the latest registers dump after we manually changed CPSW_PN_MAC_CONTROL_REG_k 0x08022330 to value 0x000200A1. Please check this package. 

I found that 

this register value is not 0. Plase alse help to check if there are other suspicious differences compared to the other port. Thanks.

Ashwani Goel said:

CPSW_PN_MAC_CONTROL_REG_k

Plese refer AM64x-TRM for explanation. Can you please capture and verify whether frames do not have any error?

12.2.1.4.6.1.1 Error Handling
In normal operation, the Ethernet port modules are configured drop received packages that contain errors (runt, frag, oversize, jabber, crc, alignment, code etc.). However, when the  CPSW_PN_MAC_CONTROL_REG_k configuration bit(s) RX_CEF_EN, RX_CSF_EN, or RX_CMF_EN are set, received Ethernet packages with errors are transferred to the host. When the ALE receives a packet that contains errors (due to a set header error bit), or a MAC control frame and does not receive an abort, the packet will be forwarded only to the host port (port 0). Packets with errors that are forwarded to the host have no VLAN untagging or drop due to rate limiting. No ALE learning occurs on packets with errors or mac control frames. Learning is based on source address and lookup is based on destination address. Directed packets from the host are not learned, updated, or touched.

Regards

Ashwani

nok3.zip

Hi Ashwani

This register value is the same as RGMII2, so I think this is not reason why RGMII can not recive frames. We just do a test on another PHY-PHY board that when we send a frame (dest mac address is FF:FF:FF:FF:FF:FF，and source address is RGMII1 mac address f4:84:4c:fb:bf:35, ), we found that RGMII1 canot receive the frame, but when we change the source address to another value, RGMII1 can receive it. In the mac2mac case , we are connecting tx channels of RGMII1 to rx channels of RGMII1, so the frames sent out from RGMII1 can never be received by RGMII1?  So RGMII can not received frames when the source mac address is the same as RGMII mac address, is that correct?

Or how can I send a frame with a different mac address from the same mac port? is it possible?

By the way, we optimized our wire connection electical condition, and the error CPSW_STAT1_IET_RX_SMD_ERROR_REG_k register don't report errors now.

I also attached our lateset register dump, please check nok3.zip.

cheng guo said:

source mac address is the same as RGMII mac address

This functionality is called source address violation. This is expected behavior.

cheng guo said:

Or how can I send a frame with a different mac address from the same mac port? is it possible?

I am not getting you packet flow. You are sending frame from FPGA-MAC to CPSW-RGMII-MAC. correct ?

Regards

Ashwani

Hello Ashwani

Our packet flow is cpsw-rgmii-mac-tx  to cpsw-rgmii-mac-rx, in the same rgmii1 interface. As there is source address violation issue, we no longger do the test now. 

We do a new test sending frame from FPGA-MAC to CPSW-RGMII-MAC just now.

But we received all error frames. CPSW_STATN_RXCRCERRORS_k and CPSW_STATN_RXALIGNCODEERRORS_k are not 0.nok4.zip

Please check the nok4.zip, all registers of CPSW are dumped.

The fpga we used can send correct frames. So the problem is likely to be caused by electrical signal interference, is that correct?

 This is our test case, please check.

Hi Ashwani

When we do the test on the board with phy, we can get the correct result.  But when we test using the board without phy and just manually connect RGMII1 tx channel to RGMII1 rx channel, we still can not receive the message. 

        Enet_Type enetType = ENET_CPSW_3G;
        Enet_Handle hEnet = Enet_getHandle(enetType, instId);
        uint32_t coreId = EnetSoc_getCoreId();

        uint8_t hostMacAddr[6] = {0xf4, 0x84, 0x4c, 0xfb, 0xc0, 0x86};

        Enet_IoctlPrms prms;
        CpswAle_SetUcastEntryInArgs setUcastInArgs;
        uint32_t entryIdx;
        /* ALE entry with "secure" bit cleared is required for loopback */
        setUcastInArgs.addr.vlanId  = 0U;
        setUcastInArgs.info.portNum = CPSW_ALE_HOST_PORT_NUM;
        setUcastInArgs.info.blocked = false;
        setUcastInArgs.info.secure  = false;
        setUcastInArgs.info.super   = false;
        setUcastInArgs.info.ageable = false;
        setUcastInArgs.info.trunk   = false;
        EnetUtils_copyMacAddr(&setUcastInArgs.addr.addr[0U], hostMacAddr);
        ENET_IOCTL_SET_INOUT_ARGS(&prms, &setUcastInArgs, &entryIdx);

        ENET_IOCTL(hEnet, coreId, CPSW_ALE_IOCTL_ADD_UCAST, &prms, status);
        if (status != ENET_SOK)
        {
            EnetAppUtils_print("Failed to add ucast entry: %d\r\n", status);
        }

We add the code for RGMII1. But still can not receive messages sent by itself. 

I alse attached the register dump, can you help to check?nok5.zip

This is our board with phy removed, clk is 30cm long to generate a 2ns delay. 

cheng guo said:

This is our board with phy removed, clk is 30cm long to generate a 2ns delay. 

I will discuss this with HW expert and get back to you.

Regards

Ashwani

Hi Ashwani

Thanks for your help.

There is alredy delay in RGMII tx clock channel, so we don't need such a long wire to generate additional delay. Now we shorten the clock line between RGMII1 tx clock and RGMII1 rx clock, we can receive messages now.

tx registers and rx registers are the same now. 

Thanks for your great help.