- NXP Forums
- Product Forums
- General Purpose MicrocontrollersGeneral Purpose Microcontrollers
- i.MX Forumsi.MX Forums
- QorIQ Processing PlatformsQorIQ Processing Platforms
- Identification and SecurityIdentification and Security
- Power ManagementPower Management
- MCX Microcontrollers
- S32G
- S32K
- S32V
- MPC5xxx
- Other NXP Products
- Wireless Connectivity
- S12 / MagniV Microcontrollers
- Powertrain and Electrification Analog Drivers
- Sensors
- Vybrid Processors
- Digital Signal Controllers
- 8-bit Microcontrollers
- ColdFire/68K Microcontrollers and Processors
- PowerQUICC Processors
- OSBDM and TBDML
-
- Solution Forums
- Software Forums
- MCUXpresso Software and ToolsMCUXpresso Software and Tools
- CodeWarriorCodeWarrior
- MQX Software SolutionsMQX Software Solutions
- Model-Based Design Toolbox (MBDT)Model-Based Design Toolbox (MBDT)
- FreeMASTER
- eIQ Machine Learning Software
- Embedded Software and Tools Clinic
- S32 SDK
- S32 Design Studio
- GUI Guider
- Zephyr Project
- Voice Technology
- Application Software Packs
- Secure Provisioning SDK (SPSDK)
- Processor Expert Software
-
- Topics
- Mobile Robotics - Drones and RoversMobile Robotics - Drones and Rovers
- NXP Training ContentNXP Training Content
- University ProgramsUniversity Programs
- Rapid IoT
- NXP Designs
- SafeAssure-Community
- OSS Security & Maintenance
- Using Our Community
-
- Cloud Lab Forums
-
- Home
- :
- Product Forums
- :
- ColdFire/68K Microcontrollers and Processors
- :
- Re: Subject: How can we prevent a receive FIFO overrun on an MCF5372 FEC
Subject: How can we prevent a receive FIFO overrun on an MCF5372 FEC
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Subject: How can we prevent a receive FIFO overrun on an MCF5372 FEC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have an MCF5372 chip.Randomly we are getting overrun error in receive side.Receive data rate is every one milli second 550 bytes of data is received.
The OV bit is set in the receive buffer and the count of "receive fifo overruns" is incremented.
As per the reference manual OV bit is set only for the below reason
19.5.15.2.1 Overrun Error
If the receive block has data to put into the receive FIFO and the receive FIFO is full, FEC sets RxBD[OV].
All subsequent data in the frame is discarded and subsequent frames may also be discarded until the
receive FIFO is serviced by the DMA and space is made available. At this point the receive frame/status
word is written into the FIFO with the OV bit set. The driver must discard this frame.
But the behaviour in my controller is different we have free descriptors but still overrun is set.
We have 16 descriptors each one with the size of 256*7 bytes.Incoming data maximum size observed is 550 bytes
When the overrun is observed i have displayed all the descriptors.
Below is the attached capture when overrun is occured
I/O: index 0
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 1
I/O: nx_mcf5372_record.pRxDescTableStart[i].status802
I/O: nx_mcf5372_record.pRxDescTableStart[i].length22a
I/O: index 2
I/O: nx_mcf5372_record.pRxDescTableStart[i].status800
I/O: nx_mcf5372_record.pRxDescTableStart[i].length71
I/O: index 3
I/O: nx_mcf5372_record.pRxDescTableStart[i].status800
I/O: nx_mcf5372_record.pRxDescTableStart[i].length71
I/O: index 4
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 5
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 6
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 7
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 8
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 9
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 10
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 11
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 12
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 13
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 14
I/O: nx_mcf5372_record.pRxDescTableStart[i].status8000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
I/O: index 15
I/O: nx_mcf5372_record.pRxDescTableStart[i].statusa000
I/O: nx_mcf5372_record.pRxDescTableStart[i].length0
Please let me know why overrun is occurred still there are free descriptors.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you searched this forum for "FEC Overrun"? There are quite a few previous instances that might be of use.
How have you got the Crossbar Switch set up? The FEC DMA must be higher priority than the CPU. Do you have USB?
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.
https://community.nxp.com/message/407754?commentID=407754#comment-407754
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:
How can we prevent a receive fifo overrun on an MCF5235 FEC
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.
Tom
