LWIP stack configuration issue on NUCLEO-H755

[iTTy]

Hi everyone!

I'm experiencing on ethernet communications using a NUCLEO-H755 board.
I already configured the LWIP stack on the M4 core and it seems work.
Now I'm trying to make it work on the M7 core following this guide:

https://community.st.com/t5/stm32-mcus/how-to-create-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308 

Compared to the guide, in my project thereare some differences:
1) Memory mapping
2) I've integrated the MX_LWIP_Process function in the main() infinite loop (instead of the udp message test).

By this way, LwIP stack seems to work also on M7: I'm able to ping my board.
But if I try to ad some more code to the infinite loop, it results in an LwIP assertion failure with this message:

"Assertion "pc->custom_free_function != NULL" failed at line 767 in C:/Users/PF5766/Documents/REPO/NucleoH755ZI/H755lwipTest/Middlewares/Third_Party/LwIP/src/core/pbuf.c"

then the board enters in Hard-fault.

/* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
	MX_LWIP_Process();

	if((HAL_GetTick() - uiCnt) >= 200U)
	{
		uiCnt = HAL_GetTick();

		HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
	}

	uiTimeOutCounter++;		// Causes Hard Fault!


  }

  /* USER CODE END 3 */

Here the code of my infinite loop on the M7.

The led blinking code gives no problems, but the uiTimeOutCounter variable increase results in the hard fault: Commenting it, will fix the hard fault.

Also leaving uiTimeOutCounter and commenting out the MX_LWIP_Process functions fix the hard fault.

It seems a MPU configuration issue. It could be?

BTW, enabling the MPU in the .ioc file, seems generate 2 functions: MPU_Initialize(void) and MPU_Config(void).

But the first one (MPU_Initialize) is only declared and never defined (giving also a warning at compile time).

Any Idea?

iTTy

P.S: I'm using CubeIDE 1.13.2, Project was generated with CubeMX 6.9.2 and H7 firware version 1.11.1 

[Piranha]

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

[iTTy]

Hi @Piranha!
Thanks a lot for your replay.
I'm already reading the post you mentioned above but since I'm a newbie on ST platform and totally new to ethernet communications, for me is a bit hard fully understand...
Anyway, since I'm on CubeMX 6.9.2 with 1.11.1 H7 FW package, I should check for reworked driver right?

Another question: Is there any way to trace the cause of the hard fault? (Register flag or similar)
I wold like to understand if LwIP causes the hard fault or it is some other...

Thank you in advance for your patience!😁

[iTTy]

Hy @Piranha ,

following the threads you collected in your umbrella-topic helped me to fix my issues.

First of all, I'm a donkey: i forgot to allocate the ETH rx pool in the ethernetif.c file (I placed the .Rx_PoolSection just after the RX and TX descriptors in the linker script).

/* USER CODE BEGIN 2 */
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
#pragma location = 0x30040600
extern u8_t memp_memory_RX_POOL_base[];

#elif defined ( __CC_ARM )  /* MDK ARM Compiler */
__attribute__((at(0x30040600)) extern u8_t memp_memory_RX_POOL_base[];

#elif defined ( __GNUC__ ) /* GNU Compiler */
__attribute__((section(".Rx_PoolSection"))) extern u8_t memp_memory_RX_POOL_base[];
#endif
/* USER CODE END 2 */

 Adding this code fixed the LWIP assertion failure.

To fix the hard fault, I shall modify the MPU configuration: basically in the ST guide (https://community.st.com/t5/stm32-mcus/how-to-create-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308 ) the memory region deicated to the ETH descriptors was limited the the descriptors only and was defined as shared-device region.
I just extended the region to the .Rx_PoolSection and defined it as Normal-Non Cacheable reagion as follow...

This configuration could be considered a valid solution ot it would be better add a further region dedicated to the descriptors?

[Piranha]

Their article doesn't configure the Rx pool memory region in MPU because the code kind of uses the D-cache maintenance functions. I am saying "kind of", because that code is incomplete and therefore flawed. Making that region normal non-cacheable solves the caching issues, but decreases the performance significantly. Previously the descriptor memory region required to be configured as a device or strongly-ordered memory type, but, as the reworked drivers now use memory barrier instructions, making it normal non-cacheable is enough. By the way, MPU regions can be overlapped and overlayed - the higher numbered region takes the charge.

Here are some related topics:

https://community.st.com/t5/stm32cubemx-mcus/lwip-v6-5-0-stmh32h735-disco-https-github-com-stm32-hotspot/m-p/91721

https://community.st.com/t5/stm32-mcus-products/maintaining-cpu-data-cache-coherence-for-dma-buffers/m-p/95746

[iTTy]

Hi folks!
I'm still there because I applied fixes above on a clone-project based on the same .ioc file to validate them in order to mark the solution in this post.

Well, in the clone-project ethernet connectivity doesn't work. No hard fault nor assertion failure, but simply I'm not able to ping the board.

My feeling is that something has been corrupted somewhere, breaking the initialization: checking the arp table on the pc, i noticed that the board IP address is missing.
What could I check to understand if the LwIP/ETH are correctly initialized?

[Piranha]

All of the issues must be fixed! Open the first link I gave and start learning and fixing. Start with the first one - the Tx deadlock.