Unmodified Stm32H723 LwIP_HTTP_Server_Socket_RTOS example gets constant RBUs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-10 11:43 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-18 8:23 AM
I'm having a similar issue on the STM32H5. The application works but I get a RBU all the time
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-19 7:59 AM
I am having the same issues too on the STM32H5
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-24 4:09 AM
Hello,
Thank you for your contribution and for bringing this to our attention.
Internal ticket number: 186958
With Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-29 12:51 PM
@ASEHST, note that the same issue is present in the Stm32CubeF7 eth drivers. The tail pointer is incorrectly being calculated
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-30 12:57 AM
@chris1seto Thank you for providing these details. We will ensure that this issue is fixed across all affected series.
With Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-07-30 1:00 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-17 9:11 AM - edited ‎2024-09-17 9:11 AM
Hello,
The RBU problem was resolved by correcting the tail pointer calculation in the following fixes:
- For the H7: [HAL][ETH] Fix the calculation of the tail pointer so that it points … · STMicroelectronics/stm32h7xx_hal_driver@ceda3ce (github.com)
- For the H5: [HAL][ETH] Fix the calculation of the tail pointer so that it points … · STMicroelectronics/stm32h5xx_hal_driver@7e8c7d8 (github.com)
Thank you.
With Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-17 1:39 PM
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!
