AnsweredAssumed Answered

MCF5485 FEC DMA doesn't update rx BD sometimes

Question asked by Yuri Tikhonov on Mar 10, 2015
Latest reply on Mar 11, 2015 by TomE

Hello,

 

We've discovered that MCF5485 DMA, which we use to receive frames from FEC, under heavy ethernet rx load doesn't update next rx BD in the table sometimes. I.e. the frame is received, but BD status & len fields may remain unchanged. We use the latest MCD DMA API (v0.3 (2004-04-26)) from Freescale to work with DMA.

 

To demonstrate the issue - here is the example of the appropriate rx BDT area snapshots, which we see on entering into 3 consecutive rx interrupt handler calls:

 

- last rx (OK):

BD

#

BD

[ST & LEN]

BD

[ADR]

Comments
1430x188002520x19EF650Just received frame
1440x900006000x19EFE50Wait for the next frame here
1450x900006000x19F0650

 

- next rx ('missed' frame):

BD

#

BD

[ST & LEN]

BD

[ADR]

Comments
1430x088002520x19EF650Previously received and processed frame
1440x900006000x19EFE50

Frame is actually rxed to [ADR], but [ST & LEN] wasn't updated !!!

1450x900006000x19F0650

 

- next rx (after miss):

BD

#

BD

[ST & LEN]

BD

[ADR]

Comments
1430x088002520x19EF650Previously received and processed frame
1440x900006000x19EFE50'Missed' frame
1450x188002230x19F0650Just received frame (after the missed one)

 

Observations are as follows:

- the DMA RX interrupt is happening on receiving this 'missed' frame,

- the 'missed' rx frame itself is actually written into the memory (into the buffer pointed by BD),

- no errors in FEC MIB counters detected in 'missed'-situations,

- 'missing' may happen at any location of BDT (we have 192 rx BD in the table),

- switching D-Cache OFF doesn't help (though we locate BDT & buffers in the noncacheable area),

- moving BDT to local SRAM (from external SDRAM) doesn't help,

- the fec driver, and the appropriate rx bd processing code was reviewed & rechecked for ~1000 times..

 

Any thoughts? Did anyone face with such FEC MCD behaviour?

 

Thanks in advance,

Yuri

Outcomes