TMS570LS3137-EP: EMAC receive packet issue RXALIGNCODEERRORS getting set

Hi,

  First of all, why are you not using the TCP/IP stack? I haven't come across anyone creating an Ethernet application directly at Link Layer level unless it's for a simple loopback test as provided by HalcoGen. I have no knowledge to answer any of your questions and debugging out of hundred of registers. I will suggest you start with the TCP/IP that abstracts the link layer. If you really need to work at link layer, we have no one that can really help you. I will suggest you look at the scope or wireshark to debug the problem. 

  BTW, what part number are you really using? Is the TMS570LS3137 or TMS570LS3137-EP?

See below description about RXALIGNCODEERRORS. You need to use a scope to see if your frame is correctly formatted and if you violate any conditions described below.  

29.5.50.6 Receive Alignment/Code Errors Register (RXALIGNCODEERRORS)
The total number of frames received on the EMAC that experienced an alignment error or code error.
Such a frame is defined as having all of the following:
• Was any data or MAC control frame that matched a unicast, broadcast, or multicast address, or
matched due to promiscuous mode
• Was of length 64 to RXMAXLEN bytes inclusive
• Had either an alignment error or a code error
– An alignment error is defined as having all of the following:
• A frame containing an odd number of nibbles
• Fails the frame check sequence test, if the final nibble is ignored
– A code error is defined as a frame that has been discarded because the EMACs MII_RXER pin is
driven with a one for at least one bit-time's duration at any point during the frame's reception.
Overruns have no effect on this statistic.
CRC alignment or code errors can be calculated by summing receive alignment errors, receive code
errors, and receive CRC errors.

As far as viewing the registers above 0x500, I think the problem is due to the GEL file that only limits the register space up to 0x400. Try this GEL file. First make a local copy of your original tms570ls3137.gel and replace with this one. The GEL directory is found at <CCS Installation>ccs\ccs_base\emulation\gel. For example, you should find the gel file in c:\ti\ccs1011\ccs\ccs_base\emulation\gel\tms570ls3137.gel. 

tms570ls3137.gel

Hi,

TMS5703137CGWTMEP is the part number. Also, the issue with viewing the registers above 0x500 is resolved with your GEL file.

It will be a point-to-point communication where large bytes need to be transferred between two devices. As I am new to EMAC peripheral, my initial plan is just to transfer some dummy bytes from one Hercules board to other Hercules board to see if the data transfer is fine at Ethernet packet level. Both the dev boards are running identical software with the same PHY device. Both devices are configured for full duplex communication.

As you had indicated, If I have to implement IPv4 with UDP, the header 28 bytes will be part of Ethernet data frame. And, I tried to frame IPv4 with UDP packet but I am not seeing anything in wireshark. So as a first step, my thought is to check if my Ethernet data transfer is correct and EMAC is configured for both transmission and reception.

Is there anything do I need to look into EMAC configuration for this issue or the data corruption is an expected behavior at 100 Mbps speed at this layer even for a point-to-point communication.

Thanks

Jai

Hi,

  As I said, without the TCP/IP stack it is extremely difficult to create Ethernet communication purely at the link layer level. As much as I'd like to help, I just don't know how. Apparently, the IP header is 20bytes without the options. I look up through Wikipedia. Not sure what you provide in the 28bytes IP header. Where did you get the IP address? You can't just write any address. What if the address is already used on your network? I don't want to be rude but I can't image someone writing an Ethernet application without the stack in real life.  What about TCP header? Without the TCP, this may explain why the wireshark is not seeing a valid TCP/IP packet. Have you used the scope or logic analyzer to probe the TX/RX pin and are they showing the correct signal?

Hi,

20 bytes IP header and 8 bytes UDP header. Thanks for your inputs.

Thanks,

Jai

Jaiganesh Jayaraman said:

Dev board_1 - Tx side: SRC and DEST address are set to 0xFF. 128 byte of data is initialized to 0xAA.

That sound like 0xAAAA will appear in the length/type. From the TMS570LS31x/21x 16/32-Bit RISC Flash Microcontroller Technical Reference Manual (Rev. C) :

According to https://en.wikipedia.org/wiki/Ethernet_frame#Types that will cause the Ethernet frame to be classed as an Ethernet II frame of Ethertype 0xAAAA. https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1 doesn't list Ethertype 0xAAAA as being an assigned type, but doesn't think cause any issue for your test trying to directly link two devices. Not sure how Wireshark would interpret it.

Jaiganesh Jayaraman said:

Is there anything do I need to look into EMAC configuration for this issue or the data corruption is an expected behavior at 100 Mbps speed at this layer even for a point-to-point communication.

Can you explain how the two devices are connected, including the PHY device configuration?

The mention of a non-zero RXALIGNCODEERROR and/or incorrect bytes received suggests a physical link error, or a possible PHY misconfiguration.

Charles Tsai said:

don't want to be rude but I can't image someone writing an Ethernet application without the stack in real life. 

To be fair, if a product only has a fixed number of devices, and not expected to be expanded, then using raw Ethernet frames with an application specific protocol could allow less overheads than using a full stack.

Hi, 

Thanks for looking into my query. As you indicated, it is going to be point to point communication and will not be part of network.

I have connected two Hercules TMS570LS31x dev boards which has PHY device DP83640. I used Halcogen code and all my EMAC and MDIO init including PHY link were successful. I have configured for MII mode and the PINMUX are set as per TRM manual section Table 29-3 and Table 29-4. Also,  PINMMR29 is set to MII mode.

On Dev Board Tx side: 

//Destination MAC address
for(i=0;i<6;i++)
EthernetTestData[i]=0xFF;

//Source MAC address
for(i=6;i<12;i++)
     EthernetTestData[i]=0xFF;

//LEN field = 1500 bytes

EthernetTestData[12]=0x05;
EthernetTestData[13]=0xDC;

for(i=14;i<1514;i++)
    EthernetTestData[i]=0x33;

MyPacket.next = NULL_PTR;
MyPacket.payload = &EthernetTestData[0];
MyPacket.tot_len = 1514;
MyPacket.len = 1514; 

//Transmit 100 frames, one frame at every 1ms rate

if(Txflag <= 100)
{
   EMACTransmit(hdkif, &MyPacket);
   Txflag++;
}

On Dev Board Rx side:

pBuf[0..5] = 0xFF

pBuf[6..10]= 0xFF

pBuf[11] = 0x7F; // This is the last byte of source address. I was expecting 0xFF

pBuf[12] = 0x01; // I was expecting 0x05

pBuf[13] = 0xD4; // I was expecting 0xDC

pBuf[14..1470] = 0xFF; // I was expecting 0x33

Here, pBuf[1471-1513] = 0x00; //This is not even updated

And following are the status of RX registers

RXALIGNCODEERRORS = 0x64 //This indicates the RX board has received 100 frames

FRAME1024TUP = 0x64

NETOCTETS = 0x250F6 // This equals 151798. Divide this by 1514 bytes/frame, 100.26 frames. Is this correct?

Additional cases:

Case 1:

If I change the data bytes to 0x11, the Rx data bytes were 0x55 and the len field were 0x01 and 0x54. The last source address byte is 0x7F.

Case 2:

If I change the data bytes to 0xAA, the Rx data bytes were '0xAA' as expected but the len field were 0x01 and 0x94. The last source address byte is 0x7F.

Please help.

Jai

Jaiganesh Jayaraman said:

I have connected two Hercules TMS570LS31x dev boards which has PHY device DP83640. I used Halcogen code and all my EMAC and MDIO init including PHY link were successful. I have configured for MII mode and the PINMUX are set as per TRM manual section Table 29-3 and Table 29-4.

If you are using the TMDS570LS31HDK can you check the state of the S2 DIP switch?

As per the TMS570LS31x Hercules Development Kit (HDK) User's Guide (Rev. C) to use Ethernet S2:4 should be ON, and S2:1 / S2:2 / S2:3 be OFF:

Looking at the TMDS570LS31HDK schematics if S2:4 and S2:1 were both on only some of the DP83640 Rx and Tx MII pins would be connected which may lead to some of your odd errors with the data. 

Hi,

I assumed the default state of these switches is OFF. So I only changed S2.4 to make Ethernet_ON on both the boards. I need to check if S2.1 was turned on inadvertently. 

Some more inputs:

1. The issue is exactly the same with Dev board - 1 transmitting and  Dev board - 2 receiving and vice-versa. The corrupted data were exactly the same in both the boards. For example, the last byte of MAC source address is 0x7F instead of 0xFF, LEN field bytes 0x0194 instead of 0x05DC on both the boards. 

2. I enabled loopback for PHY 83640 on Dev Board - 1. I could see the received data is corrupted  exactly the same way and RXALIGNCODERRORS count is 0x64. 

Note: EMAC internal loopback was fine.

3. With  PHY 83640 loopback enabled, I changed Tx Data bytes to 0xCC to see if it is specific to  MII_TXD2/3 and MII_RXD2/3 and just transmitted 1 frame of 142 bytes (128 bytes data + 14 bytes MAC header). 

Results:

pBuf[0..5] = 0xFF

pBuf[6..10]= 0xFF

pBuf[11] = 0x3F; // This is the last byte of source address. I was expecting 0xFF

pBuf[12] = 0x00; // This is ok for this test as the size is 128 bytes only

pBuf[13] = 0x00; // I was expecting 0x80

pBuf[14..127] = 0x00; // I was expecting 0xCC

pBuf[128..141] = 0x00; //Basically no update to these fields

Register information:

RXALIGNCODEERRORS = 0x01

RXGOODFRAMES = 0x00

RXBCASTFRAMES = 0x00

RXOCTETS = 0x00

TXGOODFRAMES = 0x01

TXBCASTFRAMES = 0x01

TXOCTETS = 0x92 ( = 146, 142 + 4 byte CRC)

FRAME128T255 = 0x02 //Indicates both TX and RX frames

NETOCTETS = 0x124  ( = 292, 142 + 4(CRC) + 142 + 4(CRC) //Confirms total of 2 frames with CRC 

Status of S2.1 is OFF

Thanks,

Jai

Hi,

Status of S2.1/2/3 is OFF and only S2.4 is ON.

Please see my reply above. I tried PHY loopback as well and I could see the same issue appearing.

Please help.

Thanks,

Jaiganesh

Hi, 

  I will suggest a few things for troubleshooting.

  1. First run an Ethernet application with LwIP TCP/IP stack. You can find the LwIP example from http://software-dl.ti.com/hercules/hercules_docs/latest/hercules/Examples/index.html. If the example is successfully run on the board, then it will verify if there is any issues with the board and the PHY and any settings.

  2. You need to have a scope to find out what is put out on the TX pin. You said the receiver (dev board 2) is not receiving the correct MAC address, length field and payload. The only way to find out why is to look at the scope and see the transmitting host is putting out the right data.   BTW, this is why I mentioned it is extremely difficult to create an Ethernet application without the stack. Personally, I have not done it before.

  3. Check if the transmitting host is getting any errors by looking the status register.

  4. After you run the example mentioned in 1, record all the EMAC register settings and compare with your own and see if any settings that might explain why the problem. 

  5. I will suggest you start with a very small payload so it is easier to see on the scope.  

Jaiganesh Jayaraman said:

Status of S2.1/2/3 is OFF and only S2.4 is ON.

I don't have a TMDS570LS31HDK, but did try pasting your code into a project for a TMDSRM48HDK which as far I can tell uses the same  DP83640.

As only have one HDK, connected it to an Ethernet switch to which some PCs were also connected and confirmed that Wireshark running on two connected PCs showed the 100 packets transmitted were received with the expected 1ms interval. E.g.:

Not that while your original code set the source MAC address as broadcast, I found it appears implementation defined behavior if an Ethernet switch will accept a packet with a broadcast or multicast source MAC address. E.g. found that the 4 port Ethernet switch in my broadband router forwarded packets with a source broadcast MAC address, but a managed D-Link DES-3526 switch didn't.

Therefore, in the attached program the source MAC address is a randomly allocated locally administered addresses.

Still not sure why you are getting errors in the Ethernet packets, but perhaps there is an issue with say the pin-muxing selecting in your HalCoGen project.

RM48L952_ethernet.zip