![background image](http://html1.mh-extra.com/html/texas-instruments/tms320dm36-series/tms320dm36-series_user-manual_1095290046.webp)
Architecture
www.ti.com
2.11.5
Host Free Buffer Tracking
The host must track free buffers for each enabled channel (including unicast, multicast, broadcast, and
promiscuous), if receive QOS or receive flow control is used. Disabled channel free buffer values are do
not cares. During initialization, the host should write the number of free buffers for each enabled channel
to the appropriate receive channel n free buffer count registers (RXnFREEBUFFER). The EMAC
decrements the appropriate channel’s free buffer value for each buffer used. When the host reclaims the
frame buffers, the host should write the channel free buffer register with the number of reclaimed buffers
(write to increment). There are a maximum of 65,535 free buffers available. RXnFREEBUFFER only
needs to be updated by the host if receive QOS or flow control is used.
2.11.6
Receive Channel Teardown
The host commands a receive channel teardown by writing the channel number to the receive teardown
register (RXTEARDOWN). When a teardown command is issued to an enabled receive channel, the
following occurs:
•
Any current frame in reception completes normally.
•
The TDOWNCMPLT flag is set in the next buffer descriptor in the chain, if there is one.
•
The channel head descriptor pointer is cleared to 0.
•
A receive interrupt for the channel is issued to the host.
•
The corresponding receive channel n completion pointer register (RXnCP) contains the value
FFFF FFCh.
Channel teardown may be commanded on any channel at any time. The host is informed of the teardown
completion by the set teardown complete (TDOWNCMPLT) buffer descriptor bit. The EMAC does not
clear any channel enables due to a teardown command. A teardown command to an inactive channel
issues an interrupt that software should acknowledge with an FFFF FFFCh acknowledge value to RXnCP
(note that there is no buffer descriptor in this case). Software may read RXnCP to determine if the
interrupt was due to a commanded teardown. The read value is FFFF FFFCh, if the interrupt was due to a
teardown command.
2.11.7
Receive Frame Classification
Received frames are proper (good) frames, if they are between 64 bytes and the value in the receive
maximum length register (RXMAXLEN) bytes in length (inclusive) and contain no code, align, or CRC
errors.
Received frames are long frames, if their frame count exceeds the value in RXMAXLEN. The RXMAXLEN
reset (default) value is 5EEh (1518 in decimal). Long received frames are either oversized or jabber
frames. Long frames with no errors are oversized frames; long frames with CRC, code, or alignment
errors are jabber frames.
Received frames are short frames, if their frame count is less than 64 bytes. Short frames that address
match and contain no errors are undersized frames; short frames with CRC, code, or alignment errors are
fragment frames. If the frame length is less than or equal to 20, then the frame CRC is passed, regardless
of whether the RXPASSCRC bit is set or cleared in the receive multicast/broadcast/promiscuous channel
enable register (RXMBPENABLE).
A received long packet always contains RXMAXLEN number of bytes transferred to memory (if the
RXCEFEN bit is set in RXMBPENABLE), regardless of the value of the RXPASSCRC bit. Following is an
example with RXMAXLEN set to 1518:
•
If the frame length is 1518, then the packet is not a long packet and there are 1514 or 1518 bytes
transferred to memory depending on the value of the RXPASSCRC bit.
•
If the frame length is 1519, there are 1518 bytes transferred to memory regardless of the
RXPASSCRC bit value. The last three bytes are the first three CRC bytes.
•
If the frame length is 1520, there are 1518 bytes transferred to memory regardless of the
RXPASSCRC bit value. The last two bytes are the first two CRC bytes.
•
If the frame length is 1521, there are 1518 bytes transferred to memory regardless of the
RXPASSCRC bit value. The last byte is the first CRC byte.
46
Ethernet Media Access Controller (EMAC)/Management Data Input/Output
SPRUFI5B – March 2009 – Revised December 2010
(MDIO)
Submit Documentation Feedback
© 2009–2010, Texas Instruments Incorporated