Unmodified Stm32H723 LwIP_HTTP_Server_Socket_RTOS example gets constant RBUs

[chris1seto]

Hi,

I am debugging an issue with infrequently occurring Ethernet RBU's in my own Stm32H723 application and decided to check the official Stm32 ethernet examples to see if they were having the same issue.

I imported the Stm32H723 LwIP_HTTP_Server_Socket_RTOS example and deployed it to my Stm32H723 Nucleo. I placed a breakpoint at HAL_ETH_ErrorCallback at line 565 where the rx sema is released if an rbu occurs. Sure enough, I am seeing RBUs consistently, although the application "works".

ST, surely this example should never be seeing an RBU? I am guessing there is a bug in the ethernet MAC drivers which is also affecting my application, but I'm still trying to understand how the MAC IP block works, so I haven't fully arrived at a reason myself yet. Given the descriptors should be being serviced very quickly by the application in this example, I have a hard time believing that any packets should be lost. 

[nunokisi]

I'm having a similar issue on the STM32H5. The application works but I get a RBU all the time

[STHater2]

I am having the same issues too on the STM32H5

[ASEHST]

Hello,

Thank you for your contribution and for bringing this to our attention.

Internal ticket number: 186958

With Regards,

[chris1seto]

@ASEHST, note that the same issue is present in the Stm32CubeF7 eth drivers. The tail pointer is incorrectly being calculated

[ASEHST]

@chris1seto Thank you for providing these details. We will ensure that this issue is fixed across all affected series.

With Regards,

[nunokisi]

After a brief discussion with one of my colleagues, we reached the conclusion this might have been caused by the second buffer of the descriptor. 

Since every description (read format) has two buffer addresses but the HAL only populates one, the DMA might try to access the second buffer and it is NULL. Therefore, it will set the RBU bit.

This is just a guess but it might be it.