cancel
Showing results for 
Search instead for 
Did you mean: 

Unmodified Stm32H723 LwIP_HTTP_Server_Socket_RTOS example gets constant RBUs

chris1seto
Associate III

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. 

8 REPLIES 8
nunokisi
Associate II

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

STHater2
Associate

I am having the same issues too on the STM32H5

ASEHST
ST Employee

Hello,

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

Internal ticket number: 186958

 

With Regards,

If your question is answered, please close this topic by clicking "Accept as Solution".

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

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

With Regards,

If your question is answered, please close this topic by clicking "Accept as Solution".
nunokisi
Associate II

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.

ASEHST
ST Employee

Hello,

The RBU problem was resolved by correcting the tail pointer calculation in the following fixes:

Thank you.

With Regards,

If your question is answered, please close this topic by clicking "Accept as Solution".
MS.9
Associate III

FYI - I had the same problem and the fix works

see my post (done before I found this one)

STM32H723 HAL example raises HAL_ETH_ErrorCallback on every packet, but still works!

click here to see it