Hi Paul.
I initialised FEC without further processing. I set RDAT and TDAR after enabling FEC (set ETHER_EN). Received packets were broadcast flow in LAN. I've made several tests:
1. I printed source, destination and protocol fields of received frames - common information. Our LAN has a plenty of broadcast IP and ARP packets 
2. I polled bit E in BD.status for every buffer. I a single row I've printed empty/filled status for all BDs. That's how I've got that memory corrupts when 12 buffer are filled. I haven't analyzed BD.length. I'm going to do that.
BIS
Hello BIS,
This could be a similar hardware bug we encountered in the ColdFire V2 FEC.
From the MCF5271 Device Errata:
3 FEC Receive Buffer Overrun in 10BaseT Mode
3.1 Description
When the FEC is connected to a 10BaseT network and if length of the data stored in a descriptor is not evenly divisible by 16 (not line-aligned), then the FEC will write extra lines at the end of the buffer—the entire line that contains the last valid data is written and at least one extra line, but up to four additional lines after the end of the valid data can also be written. In most cases this is not a problem, since the extra lines of data still fall within the limits of the buffer. However, if the valid data ends near the end of the buffer, then the extra lines written by the FEC might be outside of the data buffer. This leads to corruption of the next buffer, descriptor, data, or code stored in the adjacent memory.
For example, as shown in Figure 1, if the max buffer size is programmed to 0x600 and a frame that is 0x5F8 bytes long is received, then a line is written starting at buffer start + 0x5F0. The first half of the line at buffer start + 0x5F0 is valid frame data that should be processed by the FEC driver; the second half of the line is additional data that is written because the FEC will only write complete lines. This data should be ignored by the FEC driver. So far, this is correct FEC behavior as originally specified. However, the FEC will repeat the last line of valid data a number of times. The line at buffer start + 0x600 will be written, and as many as three additional lines beyond the end of the data buffer could be written.
[fig not included
]
Figure 1. Buffer Overrun Example
3.2 Workaround
There are three independent workarounds:
1. Only use 100BaseT.
2. Allocate extra lines for the receive data buffers. The actual allocated memory for each buffer should be equal to the receive buffer size programmed in the FEC’s EMRBR register plus four lines (16 byte-sized lines).
3. Program the data buffer size one line larger than the max packet size (data buffer size = EMRBR + 0x40).
I know this is fixed in a newer rev of the 5271 processor, but thought it might be relevant.
Regards,
Joel.
This could be a similar hardware bug we encountered in the ColdFire V2 FEC.
From the MCF5271 Device Errata:
3 FEC Receive Buffer Overrun in 10BaseT Mode
3.1 Description
When the FEC is connected to a 10BaseT network and if length of the data stored in a descriptor is not evenly divisible by 16 (not line-aligned), then the FEC will write extra lines at the end of the buffer—the entire line that contains the last valid data is written and at least one extra line, but up to four additional lines after the end of the valid data can also be written. In most cases this is not a problem, since the extra lines of data still fall within the limits of the buffer. However, if the valid data ends near the end of the buffer, then the extra lines written by the FEC might be outside of the data buffer. This leads to corruption of the next buffer, descriptor, data, or code stored in the adjacent memory.
For example, as shown in Figure 1, if the max buffer size is programmed to 0x600 and a frame that is 0x5F8 bytes long is received, then a line is written starting at buffer start + 0x5F0. The first half of the line at buffer start + 0x5F0 is valid frame data that should be processed by the FEC driver; the second half of the line is additional data that is written because the FEC will only write complete lines. This data should be ignored by the FEC driver. So far, this is correct FEC behavior as originally specified. However, the FEC will repeat the last line of valid data a number of times. The line at buffer start + 0x600 will be written, and as many as three additional lines beyond the end of the data buffer could be written.
[fig not included
]Figure 1. Buffer Overrun Example
3.2 Workaround
There are three independent workarounds:
1. Only use 100BaseT.
2. Allocate extra lines for the receive data buffers. The actual allocated memory for each buffer should be equal to the receive buffer size programmed in the FEC’s EMRBR register plus four lines (16 byte-sized lines).
3. Program the data buffer size one line larger than the max packet size (data buffer size = EMRBR + 0x40).
I know this is fixed in a newer rev of the 5271 processor, but thought it might be relevant.
Regards,
Joel.
