Ethernet receive stability using TCP

Receiving TCP stream that spans two packets fails after several seconds. Pings still work.

• The STM32F7 replies to the receive stream with duplicate ACK's
• The TCP stream does not recover.

Ethernet Receive Logic Review using STM32Cube_FW_H7_V1.3.2/Projects/STM32H743ZI-Nucleo/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src/ethernetif.c

• If the application waits for several pbuf's before processing receive packets there is an issue.
  • The ring buffer has 4 Ethernet packets, the packets are reassigned back to the driver, while the being queued to the LwIP stack. If the LwIP stack does not process the packets within 4 packets, the buffer is invalidated by a new incoming packet. The Rx descriptor needs to be updated with "loaned" from a local RX pbuf pool. This way, the buffers in lwIP are not invalidated by another RX an overrun.
• calls several APIs:
  • HAL_ETH_GetRxDataBuffer
  • HAL_ETH_GetRxDataLength
  • HAL_ETH_BuildRxDescriptors
  • ISR processing in the stm32h7xx_hal_ether.c HAL_ETHER_IRQHandle is called, which calls function HAL_ETH_IsRxDataAvailable , this function tests the variable AppDescNBr, the same variable is also accessed by the above functions from a Thread without any ISR locking, which may cause other issues when processing packets in the read loop and ISR when using back to back packets.

HW MAC Questions:

• Can the tail pointer for Rx register DMACRDTPR be set to 0? The goal is not to use the tail pointer and only use the ring count DMACRDLAR? So, the RX DMA only needs restart RX DMA when the all of the descriptors are assigned to processor. Have updated the driver to do this and it is working, but wanted to validated the logic.

Tim