
DocID023833 Rev 5
STM32F42xx and STM32F43xx
STM32F42xx and STM32F43xx silicon limitations
35
2.7
Ethernet peripheral limitations
2.7.1
Incorrect layer 3 (L3) checksum is inserted in transmitted IPv6 packets
without TCP, UDP or ICMP payloads
Description
The application provides the per-frame control to instruct the MAC to insert the L3
checksums for TCP, UDP and ICMP packets. When automatic checksum insertion is
enabled and the input packet is an IPv6 packet without the TCP, UDP or ICMP payload, then
the MAC may incorrectly insert a checksum into the packet. For IPv6 packets without a TCP,
UDP or ICMP payload, the MAC core considers the next header (NH) field as the extension
header and continues to parse the extension header. Sometimes, the payload data in such
packets matches the NH field for TCP, UDP or ICMP and, as a result, the MAC core inserts
a checksum.
Workaround
When the IPv6 packets have a TCP, UDP or ICMP payload, enable checksum insertion for
transmit frames, or bypass checksum insertion by using the CIC (checksum insertion
control) bits in TDES0 (bits 23:22).
2.7.2 The
Ethernet
MAC
processes invalid extension headers in the received
IPv6 frames
Description
In IPv6 frames, there can be zero or some extension headers preceding the actual IP
payload. The Ethernet MAC processes the following extension headers defined in the IPv6
protocol: Hop-by-Hop Options header, Routing header and Destination Options header.
All extension headers, except the Hop-by-Hop extension header, can be present multiple
times and in any order before the actual IP payload. The Hop-by-Hop extension header, if
present, has to come immediately after the IPv6’s main header.
The Ethernet MAC processes all (valid or invalid) extension headers including the Hop-by-
Hop extension headers that are present after the first extension header. For this reason, the
GMAC core will accept IPv6 frames with invalid Hop-by-Hop extension headers. As a
consequence, it will accept any IP payload as valid IPv6 frames with TCP, UDP or ICMP
payload, and then incorrectly update the Receive status of the corresponding frame.
Workaround
None.
2.7.3
MAC stuck in the Idle state on receiving the TxFIFO flush command
exactly 1 clock cycle after a transmission completes
Description
When the software issues a TxFIFO flush command, the transfer of frame data stops (even
in the middle of a frame transfer). The TxFIFO read controller goes into the Idle state
(TFRS=00 in ETH_MACDBGR) and then resumes its normal operation.