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.

Compiler/TMDSICE3359: PRU Ethernet issue

Part Number: TMDSICE3359
Other Parts Discussed in Thread: TLK110, , AM3358

Tool/software: TI C/C++ Compiler

Hello!

I use the TMDSICE3359 board, TLK110 chip with  reference designator U2 at the schematic. I connect it with computer (Windows 10) and use the Wireshark to snoop the ethernet packets. The  TMDSICE3359 board reads and writes the packets without errors.

But not all computers can read the packets from TMDSICE3359 board. About 40% computers can not read these packets. I take my own board (with am3358 processor) and find that it is not problem of the operation system, some ethernet controllers filters these packs. So I think I make a mistake at the write packet function or settings of the MII PRU.

When I use the RX L1 FIFO -> TX L1 FIFI -> TX MII port data path mode it works fine with all computers.

My settings:

RXCFG1 = 0x9 (RX_MUX_SEL = 1; RX_ENABLE = 1)

PRU-> TX L1 FIFI -> TX MII port data path: TXCFG1 = 0x60400301 (TX_MUX_SEL = 1; TX_CLK_DELAY = 6; TX_START_DELAY = 0x40; TX_AUTO_SEQUENCE = 1; TX_ENABLE = 1)

PRU_ICSS_CFG registers:

GP_CFG1 = 0x3 (PRU_GPI_MODE = Mii_rt_mode).

My PRU code:

void main(void)
{
	/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
    CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

    /* MII_LOOPBACK */
    __R31 = (1<<18);//rx_reset
    __R31 = (1<<30);//tx reset

    __delay_cycles(400);

    volatile int i = 1;
    volatile uint32_t rx_data;


    int arpArray[100] = {
        0xffff,//MAC
        0xffff,
        0xffff,
        0x3412,//MAC
        0x7856,
        0xbc9a,//
        0x0608,//type ARP
        0x0100,
        0x0080,
        0x0406,
        0x0100,
        0x3412,//MAC
        0x7856,
        0xbc9a,
        0x060a,//IP
        0x0201,
        0x0000,
        0x0000,
        0x0000,
        0x060a,//IP
        0x0101,
        0x0000
    };

    for (i=22; i<80; i++)
        arpArray[i] = 0x0;

    arpArray[0] = 0xffff;//without this line I write wrong MAC, I do not know why
arpArray[30] = 0xeac7;//CRC 
arpArray[31] = 0xfae9;//CRC

//if I write with command  __R31 = (1<<29)|(1<<26)|(1<<27); - CRC will be equal to 0x0, I do not know why

    while(1)//this cycle for writing only
    {
        for (i=0; i<34; i++)
            {
            __R30 = 0xFFFF0000|arpArray[i];//pack data
            __R31 = (1<<25);//push to the mii tx
            }

        __R31 = (1<<29);//EOF

        __delay_cycles(4000000);//delay between packets
	}      

    while(1)//this cycle for reading only 
        {
        rx_data = __R31;
        __R31 = (1<<17);//rx_pop16

        __delay_cycles(2);

        if ((rx_data & 1<<18) && (1<<18))//get word
            {
            CT_SHAREDMEM.mem[i] = rx_data;//write word to share mem

            i++;//pointer
            if (i >= 3000)
                i = 1;

            /* clear flags */
            if ((rx_data & 1<<22) && (1<<22))
                __R31 = (1<<20);

            CT_SHAREDMEM.mem[0] = i;//write pointer to share mem
            }

        

Firstly I was thinking that error was in case of CRC bytes absence. I was trying with and without CRC bytes, but the result was the same. Some computers can read the packet, another can not. I look at the pack structure at the PRU documentation:

I do not shure about Inter-frame logic.

The Preambule and SFD are inserted by PRU.

Data is OK (I can see it at the WireShark).

I do not shure about the CRC. When I add it, Wireshark show it and write that CRC is correct.