AnsweredAssumed Answered

MCF54455 FEC FIFO overflows occurring

Question asked by Ben Fleming on Oct 5, 2016
Latest reply on Oct 10, 2016 by TomE

I have an MCF54455 and I'm trying to debug an issue with the Ethernet FEC. When receiving packets, a large number of them end up arriving in my driver with the OV bit set in the buffer descriptor. The closest issue I have found on this site is How can we prevent a receive fifo overrun on an MCF5235 FEC which may be the same underlying issue, however I tried the suggestions there to no avail, so I suspect the root cause was not discovered. Let me describe my setup

 

MCF54455 running at 100MHz bus speed, KSZ8041NL PHY, MII connection

At both 10/100 Half/Full duplex this issue occurs.

 

Buffer Descriptors live in on chip SRAM, buffers are in SDRAM in a non-cached region

RAMBAR = 0x80000000 + 0x235 (oddly, I have tried both +0xE35 and +0x221 and not seen a significant difference)

I allocated 16 Receive Descriptors, 16 Byte aligned, and assigned them buffers of 2048 bytes, also 16 Byte aligned.

The Receive buffers flag fields get 0x8000 (E bit) set, and the final BD gets the W bit set.

MCF_FEC_RCR(ch) = (1518 << 0x10) | 0x24

MCF_FEC_EMRBR(ch) = 0x62<<4 //1568 to leave room in case FEC module overwrites end of packet

MCF_FEC_FRSR(ch) = 0x48<<2 // I've played with this as well, and it doesn't seem to affect how often the OV occurs. The manual says R_FSTART should be 0x48 or greater, it defaults to 0x40. I don't notice a difference in OV occurring, however.

 

On receive, my ISR starts at the last BD it checked previously and counts until it finds a BD marked with an empty bit (or has looped around). This count is saved and a task polls the count; if it's non-zero a receive function looks at the last BD previously read (different saved var from the ISRs 'last read'). It checks the flags, and if no error bits are set the buffer is processed, the BD gets a new buffer and is marked empty. The problem is that too often, the OV bit is set and the received packet contains some garbage. This occurs regardless of the packet size, though I think larger packets overflow earlier as a percentage of bytes (64 byte packet with 32 bytes invalid and 1518 byte packet with 1262 bytes invalid) 

 

I have tried increasing my receive buffer descriptor count up to 256, but looking at my receive processing, the number of buffers in use doesn't go much past 32, and in any case, the overflows occur throughout the list, so I'm reasonably sure that I'm not running out of buffers.


Does anyone have any idea what could be causing these overflows?

 

Thanks,

Ben

Outcomes