STM32F4 LwIP freezes when http is used for FW V1.28.0 (not for previous like V1.26.2)

[Yves_P]

Dear support,

For a custom-developed board based on an STM32F407IGT6, I’m trying to migrate my code from STM32Cube FW_F4 V1.26.2 to STM32Cube FW V1.28.0. The purpose of migration was to test the new PTP feature, but also because STM32cubeIDE uses the latest firmware version with no other choice.

The code needs to implement an HTTP server, so it uses the HAL library and LWIP without Free RTOS.

With V1.26.2 it works well; I didn’t notice any issues. With the same user code but compiled with V1.28.0, the code not related to LWIP seems to work, I can even ping the board, but as soon as an HTTP client tries to reach the server, I cannot ping the board anymore and others LWIP features seems no more accessible.

After some research, I found some topics on the forum about this (thanks to @Piranha, @DMårt and @MSG_ST    for their posts):

https://community.st.com/t5/stm32-mcus-embedded-software/http-request-to-stm32-lwip-results-that-ping-stops-working/td-p/144014/page/2

and also

https://community.st.com/t5/stm32-mcus-embedded-software/http-request-to-stm32-lwip-results-that-ping-stops-working/m-p/144014

If I follow the workaround of removing const flag in the fsdata_custom.c file then, I don’t have enough RAM memory and get an overflow during the compilation. So even if it works for smaller project (I tested it), it is not a solution in my case.

I don’t understand the argument: “It is due to Hardware limitation; in fact the Ethernet MAC does not have access to the Flash (in STM32F407 device) to download http's data”. Because I’m testing against the same hardware and have one working setup with V1.26.2 and another that fails with V1.28.0. Is there a difference in accessing memory between the 2 firmware versions ?

Some posts from ST employees also mention that this bug is known and will be fixed in the next release which should be available in June 2023. Do you have any updates on a fix for this bug; like a new release delivery time or any other workaround?

Many thanks in advance for your support

My best regards

Yves_P

[Piranha]

Yes, the ETH driver was significantly rewritten and the newer one is more broken than the older one. The new driver is zero-copy, but the ETH DMA doesn't have an access to FLASH memory on these devices. Therefore the lwIP driver should implement a code, which creates a temporary copy of such packets for a transmission, but it doesn't. The new PTP stuff is also almost useless and full of bugs like all of the HAL/Cube code is. All of this is documented there:

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-make-ethernet-and-lwip-working-on-stm32/m-p/261456

[Yves_P]

Dear Piranha,

Thanks for your message, it’s a great help for people who are struggling with the HAL library and especially when it’s combined with LwIP.

Do you know other libraries, even commercial ones that are more stable than the ST HAL version?

Going back to register, writing my library, or debugging the ST one is not an option. It’s too time-consuming and I don’t have a sufficient level of expertise.

Good also to know that PTP is also buggy, my intention was to test if improvements were done there, but it seems not. So I will not waste time to test it, thanks for sharing the info

I cannot change the hardware and it is always a nightmare when I must update my project.

Did you have experience to share with the new ThreadX suite ST integrated? I tried FreeRTOS and LWIP but it’s even worse than in bare metal (you already pointed out in other posts the memory access conflict). Zephyr is also another alternative. The idea is to benefit from other TCP stack implementations that could be more integrated and stable than LwIP could be, but I have no experience with those RTOS. I’m aware that the RTOS itself will bring more difficulties, but if it can help to have a more stable project it might be worth it

Thanks for your help

My best regards

[Alec Davis 2021]

@Yves_P 

Presumably you got this sorted, but I also had the same issue.

@DMårt,@AH_TR 

ST's positive reply to my solution today HTTP request to STM32 + LwIP results that Ping stops working 

[Yves_P]

Dear Alec,

In fact, I gave up and used a previous version of the HAL library.

But Thank you for sharing this solution, I will try it.

My best regards