![Texas Instruments SimpleLink Ethernet MSP432E401Y Скачать руководство пользователя страница 925](http://html1.mh-extra.com/html/texas-instruments/simplelink-ethernet-msp432e401y/simplelink-ethernet-msp432e401y_technical-reference-manual_1095578925.webp)
Functional Description
925
SLAU723A – October 2017 – Revised October 2018
Copyright © 2017–2018, Texas Instruments Incorporated
Ethernet Controller
Table 15-19. CRC Replacement Based on Bit 27 and Bit 24 of TDES0
Bit 27 (DC)
Bit 24 (CRCR)
Description
0
X
Append CRC
When DC = 0, the MAC appends the computed CRC irrespective of the CRCR setting.
1
1
Replace CRC
1
0
No operation (user has appended CRC)
15.3.9 Checksum Offload Engine
Communication protocols such as TCP and UDP implement checksum fields, which help determine the
integrity of data transmitted over a network. Because the most widespread use of Ethernet is to
encapsulate TCP and UDP over IP datagrams, the MAC Checksum Offload Engine (COE) supports
checksum calculation and insertion in the transmit path, and error detection in the receive path.
15.3.9.1 Transmit Checksum Offload Engine
The checksum for TCP, UDP, or ICMP is calculated over a complete frame, and then inserted into its
corresponding header field. Because of this requirement this function is enabled only when the TX FIFO is
configured for the store-and-forward mode (the TSF bit is set in the EMACDMAOPMODE register).
NOTE:
The TX FIFO must be deep enough to store a complete frame before the frame is
transferred to the MAC when the checksum offload is being used. If space is not available to
accept the programmed burst length of data, the TX/RX Controller starts reading to avoid
deadlock. When reading starts, the checksum offload fails and the consequently all
succeeding frames may be corrupted because of improper recovery. Therefore, checksum
insertion must only be enabled in frames that are less than 2048 – ((PBL + 3) × 4) bytes in
size, where PBL is the Programmable Burst Length field in the EMACDMABUSMOD register.
15.3.9.2 IP Header Checksum Engine
In IPv4 datagrams, the integrity of the header fields is indicated by the 16-bit Header Checksum field (the
eleventh and twelfth bytes of the IPv4 datagram). The checksum offload engine detects an IPv4 datagram
when the Ethernet frame's Type field has the value 0x0800 and the IP datagram's Version field has the
value 0x4. The input frame's checksum field is ignored during calculation and replaced with the calculated
value. IPv6 headers do not have a checksum field. Therefore, the checksum offload does not modify the
IPv6 header fields.
The result of this IP header checksum calculation is indicated by the IP Header Error status bit in the
Transmit status (Bit 16 in TDES0). This status bit is set whenever the values of the Ethernet Type field
and the IP header's Version field are not consistent, or when the Ethernet frame does not have enough
data, as indicated by the IP header Length field. In other words, this bit is set when an IP header error is
asserted under the following circumstances:
•
For IPv4 datagrams:
–
The received Ethernet type is 0x0800, but the IP header's Version field is not equal to 0x4.
–
The IPv4 Header Length field indicates a value less than 0x5 (20 bytes).
–
The total frame length is less than the value given in the IPv4 Header Length field.
•
For IPv6 datagrams:
–
The Ethernet type is 0x86DD but the IP header Version field is not equal to 0x6.
–
The frame ends before the IPv6 header (40 bytes) or extension header (as given in the
corresponding Header Length field in an extension header) is completely received.
If the checksum offload engine detects an IP header error, it still inserts an IPv4 header checksum if the
Ethernet Type field indicates an IPv4 payload.