![ARTERY AT32F435 Series Reference Manual Download Page 588](http://html1.mh-extra.com/html/artery/at32f435-series/at32f435-series_reference-manual_2977592588.webp)
AT32F435/437
Series Reference Manual
2022.11.11
Page 588
Rev 2.03
―
The frame ends before the IPv6 header (40 bytes) or extension header (including header
length field) has been completely received. Even if the checksum module detects such an IP
header error, it inserts an IPv4 header checksum if the Ethernet type field indicates an IPv4
payload.
TCP/UDP/ICMP checksum
The TCP/UDP/ICMP checksum determines whether the encapsulated data is TCP, UDP or ICMP by
analyzing the IPv4 or IPv6 header (including extension headers)
Note: 1. For non-TCP, UDP or - ICMP/ICMPv6 data, this checksum function is invalid and the
frame data is not modified.
2. Fragmented IP frames (IPv4 or IPv6), IP frames with security features (such as an
authentication header or encapsulated security data) and IPv6 frames with routing
headers are not processed by the checksum.
The checksum is calculated for the TCP, UDP or ICMP data and inserted into its corresponding field in
the header. It can work in the following two modes:
1.
The TCP, UDP or ICMPv6 pseudo-header is not included in the checksum calculation and is
assumed to be present in the input frame’s checksum field. The checksum field is included in the
checksum calculation, and then replaced by the final calculated checksum.
2.
The checksum field is ignored, and the TCP, UDP or ICMPv6 pseudo-header data are included into
the checksum calculation, and the checksum field is overwritten with the final calculated value.
The result of this operation is indicated by the checksum error status bit in the transmit status vector
(TDES0 bit 12). The data checksum error status bit is set when either of the following is detected:
1. The frame has been forwarded to the MAC transmitter in store-and-forward mode without the end
of the frame being written to the TXFIFO.
2. The packet ends before the number of bytes indicated by the data length field in the IP header is
received.
When the packet is longer than the indicated data length, the bytes are ignored as stuff bytes, and no
error is reported. When the first type of error is detected, the TCP, UDP or ICMP header is not modified.
For the second type of error, the calculated checksum is still inserted into the corresponding header field.
EMAC frame reception
The MAC received frames are stored into the RXFIFO and sent out by the DMA using the AHB interface.
There are two modes: Cut-through mode and store-and-forward mode.
In the default Cut-through mode, when the frame data length greater than the programmed threshold
(configured with the RTC bit in the EMAC_DMAOPM register) or a full packet of data are received in the
RXFIFO, the data are popped out and the DMA is notified of its availability. The DMA will keep popping
out the data from the RXFIFO until the data transfer is completed. Upon completion of the EOF frame
transfer, the status word is popped out and sent to the DMA controller.
In store-and-forward mode (configured by the RSF bit in the EMAC_DMAOPM register), a frame is read
by the DMA only after being written completely into the RXFIFO.
If the EMAC core is configured to drop all error frames, behavior varies in different reception modes:
1.
In store-and-forward mode, only the valid frames are read and forwarded to the application by the
DMA.
2.
In Cut-through mode, some error frames are not dropped because the error status is received at the
end of the frame.
A reception operation is initiated when the EMAC detects an SFD on the MII. The MAC core strips the
preamble and SFD before processing the frame. The header fields are checked for the filtering and the
FCS field used to verify the CRC of the frame. The frame is dropped in the core if it failed the address
filter.
If IEEE1588 time stamping is enabled, a snapshot of the system time is taken when any frame’s SFD is
detected on the MII. This time stamp is passed onto the application when the EMAC has completed the
current frame.
If the received frame length/type field is less than 0x600 and if the EMAC is configured for the auto
CRC/pad stripping option, the EMAC sends the data of the frame to RXFIFO up to the count specified
in the length/type field, then starts dropping bytes (including the FCS filed). If the length/type field is