cancel
Showing results for 
Search instead for 
Did you mean: 

Ethernet MAC, TCP Checksum offload stops working

LKert
Associate

Hi,

I'm trying to push through a lot of data over Ethernet using TCP. It's working for a while and then the TCP checksums disappear, IPv4 checksums are still there. This happens after 1-2MB -> 25GB depending if there's a python or C client on the PC, python happens more frequently, don't think this is relevant though.

In RM0090 there's a statement "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." <- this describes exactly what I'm seeing, the problem is that when it starts to happen, it never recovers on its own. Same thing happens with one 60byte packet a second.

How can one make sure the FIFO is deep enough?

Or this is always true because I'm using TCP, 1460byte MSS -> 1516byte maximum frame size which always fits into the FIFO? (by the time the prev frame was completely sent to the MAC Core transmitter)

MCU is STM32F427ZG

This is the config:

   ETH->MACCR |= (ETH_MACCR_FES |

                  ETH_MACCR_ROD |

                  ETH_MACCR_IPCO |

                  ETH_MACCR_DM);

   ETH->MACFFR = 0;

   ETH->MACFCR = 0;

   ETH->DMAOMR = (ETH_DMAOMR_DTCEFD |

                  ETH_DMAOMR_RSF |

                  ETH_DMAOMR_TSF |

                  ETH_DMAOMR_OSF);

   ETH->DMABMR = (ETH_DMABMR_AAB |

                  ETH_DMABMR_FB |

              ETH_DMABMR_RTPR_4_1 |

                  (32 << 17) | //RX Burst Length

                  (32 << 😎 | //TX Burst Length

                  ETH_DMABMR_USP |

                  ETH_DMABMR_EDE);

kind regards,

Lorand

11 REPLIES 11

... and BAM, same error, TCP header checksum all of a sudden = 0 (without using DTCM).

This is a really bad news.

How can that happen.

Anybody from ST?

@Imen DAHMEN​ @MWB_CHa​ 

Any ideas?

As I said, TCP is running for a long time, then all of a sudden it crashes due to checksum = 0 in header.

ETH register contents (MAC & DMA) still the same.

Do we have some other SRAM problem, because changes to that really influenced that behavior?

Edit: tuned down CPU clock from 216 MHz (F7 max) to 160 MHz -> running for 2 hours...

LCE
Principal

@LKert​ sorry for spamming your thread, although I think we have the same problem.

As I narrowed it down to SRAM usage / CPU clock speed, I'll make another thread.

P.S.: Now running for almost 2 hours, with using only SRAM1 and 192 MHz.