Nucleo-h743zi2 Ethernet Ping issue

[AElta.1]

hi

I am using Nucleo-H743ZI2 for Ethernet :

Ethernet RMII:

First TxDescribter Address: 0x30040060.

First RxDescribter Address: 0x30040000.

Rx Buffers Length: 1536.

MPU SETUP:

void MPU_Config(void)
{
 MPU_Region_InitTypeDef MPU_InitStruct = {0};
 
 /* Disables the MPU */
 HAL_MPU_Disable();
 
 /** Initializes and configures the Region and the memory to be protected
 */
 MPU_InitStruct.Enable = MPU_REGION_ENABLE;
 MPU_InitStruct.Number = MPU_REGION_NUMBER0;
 MPU_InitStruct.BaseAddress = 0x0;
 MPU_InitStruct.Size = MPU_REGION_SIZE_4GB;
 MPU_InitStruct.SubRegionDisable = 0x87;
 MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
 MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;
 MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
 MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
 MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
 MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
 
 HAL_MPU_ConfigRegion(&MPU_InitStruct);
 
 /** Initializes and configures the Region and the memory to be protected
 */
 MPU_InitStruct.Number = MPU_REGION_NUMBER1;
 MPU_InitStruct.BaseAddress = 0x30020000;
 MPU_InitStruct.Size = MPU_REGION_SIZE_128KB;
 MPU_InitStruct.SubRegionDisable = 0x0;
 MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
 MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
 MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
 
 HAL_MPU_ConfigRegion(&MPU_InitStruct);
 
 /** Initializes and configures the Region and the memory to be protected
 */
 MPU_InitStruct.Number = MPU_REGION_NUMBER2;
 MPU_InitStruct.BaseAddress = 0x30040000;
 MPU_InitStruct.Size = MPU_REGION_SIZE_512B;
 MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;
 MPU_InitStruct.IsBufferable = MPU_ACCESS_BUFFERABLE;
 
 HAL_MPU_ConfigRegion(&MPU_InitStruct);
 /* Enables the MPU */
 HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
 
}

LWIP: DHCP=Disabled

ip address : 192.168.1.10

netmask:255.255.255.0

default:192.168.1.1

MEM_SIZE:10*1024bytes

RAM heap pointer:0x30020000

add to STM32H743ZITX_FLASH.ld:

 /* Generate a link error if heap and stack don't fit into RAM */
_Min_Heap_Size = 0x2000 ; /* required amount of heap */
_Min_Stack_Size = 0x4000 ; /* required amount of stack */ 
 
.lwip_sec (NOLOAD) :
 {
 . = ABSOLUTE(0x30040000);
 *(.RxDecripSection) 
 
 . = ABSOLUTE(0x30040060);
 *(.TxDecripSection)
 
 . = ABSOLUTE(0x30040200);
 *(.Rx_PoolSection) 
 } >RAM_D2

add in main.c:

/* USER CODE BEGIN PV */
extern struct netif 	 gnetif;
/* USER CODE END PV */
while (1)
 {
		ethernetif_input(&gnetif);
		sys_check_timeouts();
 /* USER CODE END WHILE */
 
 /* USER CODE BEGIN 3 */
 }
 /* USER CODE END 3 */
}
 

but he when I ping the address I get :

after I do several pings it stops working which I do not understand. and I will have to run to the code again then it will work for several pings then stops. The test is done with a switch in the middle and also directly to pc with all other network connection disabled but the issue still continue.

I have tried several examples provided by STM32 for nucleo-h743zi ethernet but still does not work (the is the setup is closest I got).

I have been facing this issue with this board for a long time, I need help or solution

I searched in the community but nothing helped.

this was pervious post :

https://community.st.com/s/question/0D53W00001r8a7OSAQ/problem-using-ethernet-connection-in-nucleoh743zi2

thanks in advance

[Piranha]

It seems that the driver runs out of buffers. Therefore the question is why the buffers are not released. Maybe HAL_ETH_TxFreeCallback() function is missing.

You must use at least CubeH7 v1.10, because all of the previous versions are dysfunctional. But do not think that the current version is reliable: 

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

[MSG_ST]

Hi @AElta.1​ ,

Could you confirm that HAL_ETH_TxFreeCallback() is reached and despite that, the issue is still remaining ?

Regards

Mahdy

[eduardo_reis]

I have a similar problem. Is there any solution for this?

[tjaekel]

Yeh, looks like a buffer issue, or issue with DMA descriptors for ETH DMA located on a non-cached (or "write-through") MPU region.

You configure the total 4GB space as "not cachable"?

You add regions with "bufferable" (for 512 bytes)?
OK, makes a bit sense, except: why not using entire memory space as "not cachable"? (then it might work).

Important is: the ETH DMA descriptors (and maybe its transfer buffers) have to sit in a region with a specific cache policy (e.g. "write-trough").

If one DMA descriptor, one buffer is cached - the ETH DMA would not get anymore updated MCU instructions (e.g. that this descriptor is new) or the MCU does not see anymore the received data placed by ETH DMA (and does not act anymore, because MCU DCache sees still old data).

I would check also carefully if the MPU config matches with the source code (how many descriptors, on which location to place), and the linker script (reserved sections). Maybe at least one ETH DMA descriptors sits outside the "non-cached" region (or the .Rx_PoolSection) - it could also result in "lost communication").

I have it working on several projects, but I can remember it was "tricky" to bring all into alignment (linker script, MPU config and to use the right cache policies for ETH DMA sections). 

[eduardo_reis]

Hello @tjaekel, thank you for your response. I am pretty sure my answer is yes to all of the questions, but I will check it once more and comment soon. For the time being, I just want to give a quick comment on something you said.

---

@tjaekel wrote:

I would check also carefully if the MPU config matches with the source code (how many descriptors, on which location to place), and the linker script (reserved sections).

---

This reminded of something odd I noticed when trying to replicate the MPU configuration from the LwIP_UDP_Echo_Server example, which does not contain an .ioc file. So, when I used the .ioc file in my project, I noticed that for the region 0 it generated all fields, but not for region 1 and 2. I found that a bit odd, and I was trying to make sense out of that.

From what you said, it sounds that the STM32IDE can in fact fail to generate the code correctly for the MPU. Did I get that right?