Stm32h723 pbuf free assert, why are the ethernet drivers still broken?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-08 2:33 PM - edited ‎2023-08-08 2:36 PM
I have a project running on my Stm32H7. I imported my ethernetif/lwip settings from the Stm32CubeH7 H723 lwip + freertos http server example, but made some small changes. For the most part in the most basic sense, the driver works and my board at least gets a DHCP lease and responds to ping, but I am getting an assert:
"Assertion "pbuf_free: p->ref > 0" failed at line 753 in [......]/LwIP/src/core/pbuf.c"
I've read so many topics on the state of Ethernet in the Stm32H7. Because of the ST community manager locking threads where fixes are discussed, I honestly don't know the current state of the drivers, except I can guess that this is an issue having to do with pbufs getting clobbered. I've seen the large zip file from https://community.st.com/t5/embedded-software-mcus/bug-fixes-stm32h7-ethernet/td-p/281420, but I don't know how out of date this is or how many of these issues have truly been fixed now.
If the drivers in the CubeH7 drivers are working, what am I doing wrong? If they are not, when can we expect better fixes? The Stm32H7 has been out for 6+ years.
Thanks!
Attached are my files:
NOTE: In my code, D/ICACHE are enabled in main
Solved! Go to Solution.
- Labels:
-
STM32H7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-02-12 10:25 AM
Hello @Sankar ,@dumarjo, @kotofey,
I can confirm that this issue is related mostly to buffer sizes exceeding their dedicated memory addresses and this addressees can change based on the H7 series and if it's a dual or single core MCU . i don't know you exact issues but you can try to look for the following common mistakes:
- For STM32H72x/H73x devices, the Ethernet buffers can't be placed in address range 0x30040000 - 0x30048000, since that range is not valid. D2 SRAM on those devices is much smaller, so the buffers need to be placed starting at 0x30000000. This affects RX & TX descriptors and RX buffer addresses (ETH configuration in CubeMX) and LWIP_RAM_HEAP_POINTER used for TX buffers .
- When running the stack on Cortex-M4, the buffers can be placed at the same address (0x30040000), but it is better to place them at 0x10040000 which is alias for the same address. This alias is accessible by Cortex-M4 D-bus and helps to utilize the Harvard architecture.
- On STM32H747-Discovery board, modification needs to be done to default solder bridge configuration. SB8 should be closed and SB21 should be open for Ethernet to work, otherwise the MDC signal is not properly connected.
- When allocating buffers via pbuf_alloc (or similar), PBUF_RAM must be used as 3rd parameter. This is necessary to ensure that the allocated buffer is placed in D2 SRAM and synchronized with DMA
- Not sufficient stack size for different thread can cause issues.
a detailed explanation on the setup of Ethernet and LWIP on STM32H7 can be found in this article .
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-08 2:34 PM
Because of forum restrictions, I needed to reply to get my last file in.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-10 6:04 PM
Bump @Amel NASRI @STOne-32 I'd really appreciate some help with this issue.
Thanks,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-11 9:36 AM
Dear @arena_chris1seto ,
Thank you for the follow-up, the best is to contact our official support Online support Tool, so to get a direct contact with our regional teams and exchange to debug your application. However I may suggest to check the management of the Heap if using internal RAM and its configuration with the physical RAM with the product you are using. You can see here is on our STM32H7 series : STM32H7 - Arm Cortex-M7 and Cortex-M4 MCUs (480 MHz) - STMicroelectronics RAM size differs a lot from a part to another 1 Mbytes in H747 and 546Kbytes in H723.
Hope it helps you .
Ciao
STOne-32
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-11 11:38 AM
Thanks @STOne-32 .
I have to admit, I'm a little disappointed we can't work through this issue on a public forum where others can benefit from it. I don't understand why ST is so afraid of addressing issues with the Ethernet drivers. There seems to be a legitimate fear among the forum staff when these issues are brought up. Topics locked, useless answers, posts ignored. I really don't get it.
Can you please get me a direct contact to someone within ST who knows the Ethernet hardware well so we can solve this once and for all?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-12 3:35 AM - edited ‎2023-08-14 5:55 AM
Dear @arena_chris1seto ,
Indeed, there is no particular point different on Ethernet versus any other peripheral such I2C or SPI for our approach in private or public way ( you can look to our quite long errata) . However, so far we do not have in our public community ( World Wide digital coverage ) among moderators experts on Ethernet to go to debug each customer code , our current approach is to help you with our direct FAEs, or other experts from community on same topic which seems also not the case and Only ST is able to help, We need an internal escalation and to reach the colleagues in charge of it . Our main strategy is to have a wide community of experts helping experts like you :) across the world .Your feedback is much appreciated and we will be back to you in a mid term with more focus approach on this topic
Ciao
STOne-32
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-14 4:30 AM
We try to check your issue related to buffer allocation in LwIP RTOS application.
Could you please provide some more info about the environment that you use ?
- Which STM32H7 CubeFW version ?
- Which STM32CubeMX version ? (if used to generate the code)
- Could you please precise when do you get the assert issue ? (ie. at specific ping size, random, ...)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-14 10:00 AM
@MWB_CHa
Thanks for the response. I'm using the latest 1.11.0 CubeH7. I'm not using the CubeIDE, but I did check my code against the example code (Stm32HubeH7 netconn http RTOS) and the auto generated code. The pbuf assert usually happens a bit after bootup, or just randomly past that. I also get Assertion "memp_free: mem properly aligned" failed.
@STOne-32 I think the best feedback I could give here is that ST needs to do a complete review of the current ethernet drivers and fix the issues which seem to be constantly reported here. I'm not an expert in the cache support on the M7, but it seems like there is something deeply unhealthy related to caching and/or the memory management used in the examples. There are numerous topics where people complain about the same general pbuf assert issues (like this one). Several users have brough up numerous points of improvement, and it's unclear why ST ignores these suggestions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-14 10:14 AM - edited ‎2023-08-14 10:17 AM
Dear @arena_chris1seto ,
Thank you for the case entered in our online support channel last friday. My colleagues in Brazil and @MWB_CHa will be back to you soon with actions related to our ethernet drivers as mentioned above and then to publish to all on community.
Regarding Cortex-M7 core and Cache management indeed here are two applications notes at application level to handle :
1) Level 1 cache on STM32F7 Series and STM32H7 Series AN4839 ( Chapter 3 & 4 )
2) Introduction to memory protection unit management on STM32 MCUs - Application note AN4838
Cheers,
STOne-32
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-08-22 3:01 PM
Dear @arena_chris1seto ,
Just got the confirmation from our technical teams , that they provided you some pointers to explain the issue . Please let us know if it might be the root-cause . Thank you again for the patience and understanding.
Ciao
STOne-32
