MCBSTM32EXL Keil, MCBSTM32EXL Datasheet - Page 857

• Manufacturer Part Number: MCBSTM32EXL
• Description: BOARD EVALUATION FOR STM32F103ZE
• Manufacturer: Keil

Specifications of MCBSTM32EXL

• Lead Free Status / RoHS Status: Lead free / RoHS Compliant

RM0008
2
You must make sure the Transmit FIFO is deep enough to store a complete frame before
that frame is transferred to the MAC Core transmitter. If the FIFO depth is less than the input
Ethernet frame size, the payload (TCP/UDP/ICMP) checksum insertion function is bypassed
and only the frame’s IPv4 Header checksum is modified, even in Store-and-forward mode.
The transmit checksum offload supports two types of checksum calculation and insertion.
This checksum can be controlled for each frame by setting the CIC bits (Bits 28:27 in
TDES1, described in
See IETF specifications RFC 791, RFC 793, RFC 768, RFC 792, RFC 2460 and RFC 4443
for IPv4, TCP, UDP, ICMP, IPv6 and ICMPv6 packet header specifications, respectively.
●
●
IP header checksum
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 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 by the calculated value. IPv6
headers do not have a checksum field; thus, the checksum offload does not modify
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). 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:
a)
–
–
–
b)
–
–
TCP/UDP/ICMP checksum
The TCP/UDP/ICMP checksum processes the IPv4 or IPv6 header (including
extension headers) and determines whether the encapsulated payload is TCP, UDP or
ICMP.
Note that:
a)
b)
For IPv4 datagrams:
The received Ethernet type is 0x0800, but the IP header’s Version field does not
equal 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 does not equal 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) has been
completely received. Even when the checksum offload detects such an IP header
error, it inserts an IPv4 header checksum if the Ethernet Type field indicates an
IPv4 payload.
For non-TCP, -UDP, or -ICMP/ICMPv6 payloads, this checksum is bypassed and
nothing further is modified in the frame.
Fragmented IP frames (IPv4 or IPv6), IP frames with security features (such as an
authentication header or encapsulated security payload), and IPv6 frames with
routing headers are bypassed and not processed by the checksum.
TDES1: Transmit descriptor Word1 on page
Ethernet (ETH): media access control (MAC) with DMA controller
Doc ID 13902 Rev 9
889).
857/995