Showing results for 
Search instead for 
Did you mean: 

How to get Ethernet working again after upgrading to firmware FW_H7_V1.4.0 ?

Associate II

I had several projects running, created with STM32CubeMX. Among them also the example H743ZI_LwIP_test1. Things were fine with firmware 1.3.0 and 1.3.2 but after upgrading to 1.4.0 , I can no longer connect to the network. No ping, no nothing. Currently I test with the NUCLEO-H743ZI board.

I compared .ioc files and various code source, but couldn't find any

Any help welcome,

thanks in advance



Accepted Solutions
Associate II

An Update to this

As I initially wrote that problem occurred with the H7 firmware update from FW_H7_V1.3.0 to FW_H7_V1.4.0. After being busy with other projects I resumed MCU programming still with the H7 family and meanwhile CubeMX is at V5.5 and H7 firmware at FW_H7_V1.6.0.

Good News the above problem seems gone.

When comparing the code generated now to before one finds some differences in the ethernetif.c file, the relevant to me seems in function low_level_input(...) :

old code:

#if defined(DUAL_CORE) && defined(CORE_CM7) 

  /* Invalidate data cache for ETH Rx Buffers */

  SCB_InvalidateDCache_by_Addr((uint32_t *)RxBuff.buffer, framelength);


new code:

#if !defined(DUAL_CORE) || defined(CORE_CM7)

  /* Invalidate data cache for ETH Rx Buffers */

  SCB_InvalidateDCache_by_Addr((uint32_t *)RxBuff.buffer, framelength);


As you can see the #if has changed resulting that the call to SCB_InvalidateDCache_by_Addr is now active while it wasn't before.

My guess is that the ST programmers made a mistake when adapting the template file (ethernetif_h7.ftl) for the dual core H7x5x and later corrected it.

BTW: when using the ADCs again SCB_InvalidateDCache_by_Addr() is a good friend to make the DMA mode working.

View solution in original post

Associate II

I have the samme problem with the new firmware.

If I use the http example that comes with the 1.4 firmware for running a tcpEcho test it works fine, so it must be something about how cubemx generate the code.

I suspect it has something to do with the ethernetif.c, because if you copy the ethernetif.c file from a 1.3.0 CubeMx project to your 1.4.0 project the ping will work but the connection is not stable.

It is a shame that ST did not pay more attention to the CubeMx code generation with the new firmware, because testing their examples it seems they finally made a usable ethernet implementation for the H7.

Francesco Agosti
Associate II

I am not sure if there is a problem with the firmware or it is just me, in fact I am trying to learn LWIP with the nucleo144 /H734ZI.

If I compile the example project (httpd with RTOS) it works, I even modified the webserver a bit and got the overall idea of how it works, it was a useful exercise... but then when I try to create a project from scratch in CubeIde (fw 1.4.0) with RAW TCIPP I cannot even get the ping workking.

This is what I did :

1) Enable D-Cache

2) Set ETH as RMII

3) Enable LWIP, static address (same IP config I used in the httpd example)

4) Ensure ICMP is enabled

5) generate code

6) add MX_LWIP_Process(); in the main loop (MX_LWIP_Init() is called before the loop, code generated by Cube

The network interface seems to be set up the same way I saw in the httpd example, but this one does not work, for whatever reason I get no answers to the ping.

Does anyone have some basic working example on how to setup raw tcpip communications with cubeMX and lwip? Am I missing any steps?



Associate II

Hi Francesco,

the STM32H7 MCUs are somehow more demanding when you want to use the Ethernet than for example the STM32F7 family. For the STM32H7 you must activate and configure the MPU and also add some lines to the FLASH.ld file. There is a project example here: (the one I mentioned above). However this worked for me only until firmware 1.3.2 and not with 1.4.0.

I do not know whether using the IDE makes a difference compared to CubeMX , but I am pretty sure that without the MPU you cannot use the ethernet nor LwIP.

If you can get hold of a NUCLE-F746ZG board than you will find it far easier to use. I consider to use an STM32F767 instead the STM32H753.

Good luck,


Francesco Agosti
Associate II

Thanks a lot Peter, that really helps. Checking the Github example.


Associate II

OK, I think I located/solved the problem and this ****** me off completely with ST since I wasted several days by debugging their code...

Basically they removed the the calls


from the ethernetif_h7.ftl file which came with the CubeMX update to MxDb.Version=DB.5.0.20. Those calls are needed for the low_level_input/output to function. I develop with macOS, the templates are found in /Applications/STMicroelectronics/ .

BTW, did anyone ever use the Template Settings of the Project Manager successfully? To me it looks like it is not working at all. I replaced the template file from the command line.

Good luck to everyone in getting their project back to work.



Hi all,

To resolve this issue, it is necessary to change the ETH MAC address of a local network adapter because an application is requesting a particular one to work, or sometimes because there is a conflict with another MAC address on the same network, or to avoid being traced.

The MAC hardware address is not used directly, which makes it possible to modify it at the software and not the physical level, it is then modifiable by the user. Its change reduces the risk of tracing inherent to any immutable identifier.

For this fact :

1- Open STM32Cube_FW_H7_V1.4.0 \ Projects \ NUCLEO-H743ZI \ Applications \ LwIP \ LwIP_HTTP_Server_Netconn_RTOS \ EWARM

2- Open the file stm32h7xx_hal_conf.h

3- Change the definition of ETH_MAC_ADDR5 from 0x00 to 0x20 for example

4- Save and debug the program.

You can connect now to the network 

Best Regards,


Associate II

I think you should read the thread again. The example shipped with the firmware works fine, it is when you create a project created with CubeMX the problems appear.

This is MVP of the year. thanks for sharing

Chief II

The "fix" using SCB_CleanInvalidateDCache() is also flawed!

Input buffers can't be cleaned as it will corrupt them. And all memory also can't be cleaned, because it will also clean the input buffers, not even talking about making cache partly useless and therefore everything running slower. Also whole memory wide cache operations are much slower than *_by_Addr() ones.

Correct solution:

  1. low_level_input() - One has to use SCB_InvalidateDCache_by_Addr() here on an actual input buffer and address and size of all input buffers must be aligned to __SCB_DCACHE_LINE_SIZE. In CubeMX v5.4.0 the SCB_*() call is correct, but buffer alignment isn't.
  2. low_level_output() - One has to use SCB_CleanDCache_by_Addr() here in a loop on every buffer segment. In CubeMX v5.4.0 this is missing. Example of a correct fix:
for(q = p; q != NULL; q = q->next)
	if(i >= ETH_TX_DESC_CNT)	
		return ERR_IF;
	SCB_CleanDCache_by_Addr(q->payload, q->len);
	Txbuffer[i].buffer = q->payload;
	Txbuffer[i].len = q->len;
	framelen += q->len;

For a complete list of STM32 networking issues, see my topic: