Stm32h723 pbuf free assert, why are the ethernet drivers still broken?

[arena_chris1seto]

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

[arena_chris1seto]

Because of forum restrictions, I needed to reply to get my last file in. 

[arena_chris1seto]

Bump @Amel NASRI @STOne-32 I'd really appreciate some help with this issue.

Thanks,

[STOne-32]

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

[arena_chris1seto]

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? 

[STOne-32]

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

[MWB_CHa]

Hi @arena_chris1seto 

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, ...)

[arena_chris1seto]

@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.  

[STOne-32]

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

[STOne-32]

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

[kotofey]

Do you have any solution? I have exactly the same problem with pbuf assert.

[dumarjo]

Any update ? I have the exact same problem.

 

[Sankar]

hi, i am also facing similar problem. did you get the solution? could you help ? 

 

Sankar

[STOne-32]

Dear @Sankar ,

can you please your project with @STea , we will help you . The original post thread has been solved with right settings of memories and heap size .

please share your code & setup and failing part of code .

Cheers,

STOne-32

[STea]

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:

1. 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 .
2. 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.
3. 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.
4. 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
5. 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

[hasseb]

If you have any memory issues wit lwip and FreeRTOS you should keep in mind that lwip is not thread safe by default. Netapi should be thread safe, but if you are using any other lwip functionality from multiple threads you should know what you are doing.

I recommend to move all network related tasks to the same priority as TCP/IP task and disable time slicing to see if it solves your issues. You can also test disabling all tasks calling lwip function to see if it helps.