Ethernet receive stability using TCP

[Tim Michals]

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

[R Piacenzia]

I can't help with the other issues, but regarding your "calls several APIs" question. I recently asked ST about HAL_ETH_IsRxDataAvailable() being called by the ISRHandler and also the CMSIS driver without any locking, and ST indicated:

[ST Response ] It's fixed and will be part of the next release 1.4.0 Regards.

This is referring to the next release of the STM32H7 HAL ETH driver. It is currently 1.3.0.

In my case this problem was causing intermittent crashes of the ETH driver and network.

[Tim Michals]

When is 1.4.0 going to be released?

[kakukz493]

Was stuck on this bug for a good few days since you actually has to see what Keil is doing in their ETH rx proccess thread to figure out whats wrong.

Also was totally random when the ETH driver got locked. This fix is for Keil MDK, I cant say anything about other network stacks.

For a quick patch comment this line out in the HAL driver source file stm32h7xx_hal_eth.c:1169 (DFP 2.2.0):

if(HAL_ETH_IsRxDataAvailable(heth) == 1) => //if(HAL_ETH_IsRxDataAvailable(heth) == 1)