<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>ColdFire/68K Microcontrollers and ProcessorsのトピックRe: Subject: How can we prevent a receive FIFO overrun on an MCF5372  FEC</title>
    <link>https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Subject-How-can-we-prevent-a-receive-FIFO-overrun-on-an-MCF5372/m-p/641795#M13120</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Have you searched this forum for "FEC Overrun"? There are quite a few previous instances that might be of use.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;How have you got the Crossbar Switch set up? The FEC DMA must be higher priority than the CPU. Do you have USB?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Here's one with a lot of details where the symptom was a failed TRANSMIT with Underrun. That was due to the Reference Manual not having a sentence that was in nearly all other device manuals, which is to be sure to initialise R_FSTART.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A _jive_internal="true" class="link-titled" href="https://community.nxp.com/thread/324296?commentID=407754#comment" title="https://community.nxp.com/message/407754?commentID=407754#comment-407754"&gt;https://community.nxp.com/message/407754?commentID=407754#comment-407754&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Here's a good one where the poster "found the problem", but his explanation didn't make sense. Lots of things to read and try in these, anyway:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.nxp.com/thread/318121"&gt;How can we prevent a receive fifo overrun on an MCF5235 FEC&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;There are a lot of people successfully using the FEC on these parts without any problems. If you have a problem it is most likely to be a software bug where you're not "doing the right thing by the chip". But finding out what that is is usually more than reading the manual.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Tom&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Thu, 29 Sep 2016 15:02:30 GMT</pubDate>
    <dc:creator>TomE</dc:creator>
    <dc:date>2016-09-29T15:02:30Z</dc:date>
    <item>
      <title>Subject: How can we prevent a receive FIFO overrun on an MCF5372  FEC</title>
      <link>https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Subject-How-can-we-prevent-a-receive-FIFO-overrun-on-an-MCF5372/m-p/641794#M13119</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;We have an MCF5372 chip.Randomly we are getting overrun error in receive side.Receive data rate is&amp;nbsp; every one milli second 550 bytes of data is received.&lt;BR /&gt;The OV bit is set in the receive buffer and the count of "receive fifo overruns" is incremented.&lt;/P&gt;&lt;P&gt;As per the reference manual OV bit is set only for the below reason&lt;/P&gt;&lt;P&gt;19.5.15.2.1 Overrun Error&lt;BR /&gt;If the receive block has data to put into the receive FIFO and the receive FIFO is full, FEC sets RxBD[OV].&lt;BR /&gt;All subsequent data in the frame is discarded and subsequent frames may also be discarded until the&lt;BR /&gt;receive FIFO is serviced by the DMA and space is made available. At this point the receive frame/status&lt;BR /&gt;word is written into the FIFO with the OV bit set. The driver must discard this frame.&lt;/P&gt;&lt;P&gt;But the behaviour in my controller is different we have free descriptors but still overrun is set.&lt;BR /&gt;We have 16 descriptors each one with the size of 256*7 bytes.Incoming data maximum size observed is 550 bytes&lt;BR /&gt;When the overrun is observed i have displayed all the descriptors.&lt;BR /&gt;Below is the attached capture when overrun is occured&lt;/P&gt;&lt;P&gt;I/O: index 0&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 1&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status802&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length22a&lt;BR /&gt;I/O: index 2&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status800&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length71&lt;BR /&gt;I/O: index 3&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status800&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length71&lt;BR /&gt;I/O: index 4&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 5&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 6&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 7&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 8&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 9&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 10&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 11&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 12&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 13&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 14&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].status8000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;BR /&gt;I/O: index 15&lt;BR /&gt;I/O:&amp;nbsp; nx_mcf5372_record.pRxDescTableStart[i].statusa000&lt;BR /&gt;I/O: nx_mcf5372_record.pRxDescTableStart[i].length0&lt;/P&gt;&lt;P&gt;Please let me know why overrun is occurred still there are free descriptors.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 22 Sep 2016 08:59:39 GMT</pubDate>
      <guid>https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Subject-How-can-we-prevent-a-receive-FIFO-overrun-on-an-MCF5372/m-p/641794#M13119</guid>
      <dc:creator>sambuharikrishn</dc:creator>
      <dc:date>2016-09-22T08:59:39Z</dc:date>
    </item>
    <item>
      <title>Re: Subject: How can we prevent a receive FIFO overrun on an MCF5372  FEC</title>
      <link>https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Subject-How-can-we-prevent-a-receive-FIFO-overrun-on-an-MCF5372/m-p/641795#M13120</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Have you searched this forum for "FEC Overrun"? There are quite a few previous instances that might be of use.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;How have you got the Crossbar Switch set up? The FEC DMA must be higher priority than the CPU. Do you have USB?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Here's one with a lot of details where the symptom was a failed TRANSMIT with Underrun. That was due to the Reference Manual not having a sentence that was in nearly all other device manuals, which is to be sure to initialise R_FSTART.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A _jive_internal="true" class="link-titled" href="https://community.nxp.com/thread/324296?commentID=407754#comment" title="https://community.nxp.com/message/407754?commentID=407754#comment-407754"&gt;https://community.nxp.com/message/407754?commentID=407754#comment-407754&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Here's a good one where the poster "found the problem", but his explanation didn't make sense. Lots of things to read and try in these, anyway:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="https://community.nxp.com/thread/318121"&gt;How can we prevent a receive fifo overrun on an MCF5235 FEC&lt;/A&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;There are a lot of people successfully using the FEC on these parts without any problems. If you have a problem it is most likely to be a software bug where you're not "doing the right thing by the chip". But finding out what that is is usually more than reading the manual.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Tom&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 29 Sep 2016 15:02:30 GMT</pubDate>
      <guid>https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/Subject-How-can-we-prevent-a-receive-FIFO-overrun-on-an-MCF5372/m-p/641795#M13120</guid>
      <dc:creator>TomE</dc:creator>
      <dc:date>2016-09-29T15:02:30Z</dc:date>
    </item>
  </channel>
</rss>

