MPC5777M FEC Buffer Descriptors

[amorris]

Hi there,

I've been sitting on this problem for a while now. I have FEC (MII mode) working to communicate to my external PHY which I can communicate with using full duplex 100MBps. I currently have 16 RX Buffer Descriptors defined in software which i cycle through and mark as empty when read from (or in the case of the final bd, empty and wrap). This all works fine except that upon reception of data (polling FEC.EIR.B.RXF), the RX Buffer Descriptor pointed to by FEC.ERDSR.R updates multiple buffers with the data received. I am using buffer size 1536 and all buffers and buffer descriptors are 128-bit aligned as recommended. Has anyone experienced any issues like this?

Cheers.

[martin_kovar]

Hi,

did you look at this application note?

http://cache.nxp.com/files/32bit/doc/app_note/AN4577.pdf?fsrch=1&sr=1&pageNum=1

There are also four examples including source codes, which you can use.

http://cache.nxp.com/files/32bit/doc/app_note/AN4577SW.zip

Examples are created for MPC5644B, but the module is similar as for MPC5777M.

Please try and eventually write me back, if it helped you.

Regards,

Martin

[amorris]

Hi Martin,

Using the attached code (Modified for MPC5777M pins) I encounter the same problem. There are only 2 buffer descriptors, so if i receive an ethernet frame, both descriptor's buffers are updated with the frame and marked as full by the hardware. I then process only a single buffer descriptor as it should be. If i then send another - different - ethernet frame, the processing code reads the second descriptor as it should, however the data is still the previous frame. I can then send a third frame, and the code processes the first buffer again, of course containing the second frame. So it works to an extent, but i need to process the data twice and need to send an extra ethernet frame to toggle the RXF high again.

Interestingly enough, the problem does not occur in loopback, only with physical media attached.

Cheers,

Andrew

[martin_kovar]

Hi Andrew,

at first, what is the second side which your micro communicates with? Is it PC or something else? How many frames do you send? Do you send one or more frames? If you send only one frame and two buffer descriptors are updated, then it is strange. Are you able to check, what is the size of the frame you send?

Could you please send me status register of the buffer descriptors? This could tell us some helpful information.

Also, if two descriptors are updated, you have to manage both of them and then set buffers as empty.

Regards,

Martin

[amorris]

Martin,

The other side of the comms has been multiple devices. At a testing level, i used a linux pc to avoid the overheads presented by a windows pc's network interface, and sent only a single packet. From the single RXF toggle that occurred, both buffer descriptors are updated.

Managing both buffer descriptors is a solution, however, i was more hoping to find the cause rather than implement a workaround.

Status register of the buffer descriptors reflect 0x8000 and 0xA000 for empty and wrap and empty when i clear them. When updated they are 0x0800 and 0x2900 respectively.

Regards,

Andrew

[martin_kovar]

Hi Andrew,

from my point of view it looks like the IP packet you send it bigger than 1500 bytes. Are you able to check, whether the IP packet is not bigger than 1500 bytes? What tool do you use for packet generation?

Ethernet has frame size limitation . Maximal frame size is 1518 bytes (1522 bytes if you use 802.1Q VLAN tagging). If IP packet including header is bigger than 1500 bytes, it is divided and encapsulated into more Ethernet frames. I ask about this, because it is strange you have updated both buffers with different status.

Are data in both buffers the same or different?

Could you please try to use interrupt instead of RXF polling and debug your code in the interrupt? Are still both buffers updated in single interrupt?

Regards,

Martin

[amorris]

Hi Martin,

Apologies for the delay in response. I'm using python udp scripts to generate the packets and verifying the integrity and size using wireshark. They are definitely no larger than 1500 bytes. The length of each BD reflects the correct size of the packet im sending. I can attempt an interrupt based reception instead of polling in the near future (pushed for time right now unfortunately) - for the time being i have put a workaround in place to check for length not equal to zero of the buffer descriptor in the RXF polling routine and discarding the contents if RXF is not also high. This is working robustly currently with 12 hour regression tests at 15ms interval between packets at 100MBPS full duplex; so will suffice for now. Thankyou for your assistance.

Regards,

Andrew