Skip to main content
Associate II
September 27, 2024
Question

Issue with LWIP heap

  • September 27, 2024
  • 15 replies
  • 6511 views

Hello everyone,

I'm having issues with the Heap of the LWIP that is used/full, and I can't do any mem_malloc. 
I have dig a bit on why the log of LWIP tells me that  it couldn't allocate memory ("etharp_raw: could not allocate pbuf for ARP request"). As far as i understand, the mem_malloc used the struct mem *lfree variable to handle the allocation for the LWIP and which is the next/previous chuck and also if the next chunk is being used or not.

 

 

struct mem {
 /** index (-> ram[next]) of the next struct */
 mem_size_t next;
 /** index (-> ram[prev]) of the previous struct */
 mem_size_t prev;
 /** 1: this area is used; 0: this area is unused */
 u8_t used;
#if MEM_OVERFLOW_CHECK
 /** this keeps track of the user allocation size for guard checks */
 mem_size_t user_size;
#endif
};

 

 

My issue is that the variable used in the mem struct is never null or zero. Which lead to the mem_malloc to always return NULL even after a fresh upload or power up.  

I manage to track down what appear to be written in the memory area dedicated for the LWIP heap. It occurs in the HAL_ETH_MspInit ("void HAL_ETH_MspInit(ETH_HandleTypeDef* ethHandle)") with the line "__HAL_RCC_ETH1MAC_CLK_ENABLE();"  as you can see in the picture

> FAV_Before-__HAL_RCC_ETH1MAC_CLK_ENABLE.PNG

FAV_Before-__HAL_RCC_ETH1MAC_CLK_ENABLE.PNGFAV_Before-__HAL_RCC_ETH1MAC_CLK_ENABLE.PNG

> FAV_After-__HAL_RCC_ETH1MAC_CLK_ENABLE.PNGFAV_After-__HAL_RCC_ETH1MAC_CLK_ENABLE.PNGFAV_After-__HAL_RCC_ETH1MAC_CLK_ENABLE.PNG

Before the call, the ram is zero, after the call the ram is full.  You can also see in the Expressions panel on the right that before the call, lfree is empty, and after the call lfree is not empty anymore and point to some random chunk.

 

The really strange thing is that the same code can work for a while, but once the ram is used, i'm stuck.

 

I'm using the STM32H743ZI on a custum PCB with the LAN8742 .
I also tested the same code on the Nucleo-H743ZI2 and i'm having difference result with the same function 

> Nucleo-Before-__HALL_RCC_ETH1MAC.PNG

TCP_OK_Nucleo-Before-__HALL_RCC_ETH1MAC.PNGTCP_OK_Nucleo-Before-__HALL_RCC_ETH1MAC.PNG

> Nucleo-After-__HALL_RCC_ETH1MAC.PNGTCP_OK_Nucleo-After-__HALL_RCC_ETH1MAC.PNGTCP_OK_Nucleo-After-__HALL_RCC_ETH1MAC.PNG

As you can see with the nucleo, the ram is not null/zero before the call and after the call as well, but the field "used"  is zero, and i can therefore call mem_malloc without any issue. 

 

I'm providing you the ETH_ICO config, the LWIP_ICO config, and the change i made in the FLASH.ld

> ETH_IOC_Config.PNG

ETH_IOC_Config.PNGETH_IOC_Config.PNG

> LWIP_FLASH_ld.PNG

LWIP_FLASH_ld.PNGLWIP_FLASH_ld.PNG

> LWIP_IOC_Config.PNG

LWIP_IOC_Config.PNGLWIP_IOC_Config.PNG

 

For the LWIP and ETH configuration in the ICO, I have follow this guide/serie : 

https://controllerstech.com/stm32-ethernet-1-connection/ 

 

If you have any question, feel free to ask.
I hope someone could help as I'm stuck with this issue since last week without any lead.

 

 

15 replies

Visitor II
June 24, 2026

I have exactly the same problem with a nucelo h723zg board. Is there any solution? __HAL_RCC_ETH1MAC_CLK_ENABLE seems to corrupt the memory. What is going on here? The issue disappears and reappers sporadically.

Pavel A.
June 24, 2026

ETH has its own master DMA that can write memory of the host asynchronously. With enough [bad] luck, enabling the ETHMAC clock can trigger the DMA, or the eth interrupt.

 

Visitor II
June 25, 2026

I’v found another thread. It was recommended to call __HAL_RCC_D2SRAM1_CLK_ENABLE() in clock config and it seems to do the trick for me.

Any chance CubeMX code generator will get an update to get rid of this ‘non-deterministic behavior’?