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

[PHoll]

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

Peter

[kold]

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]

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?

Thanks

Francesco

[PHoll]

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: https://github.com/MX-Master/STM32H7_Nucleo-H743ZI_Ethernet_LwIP (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,

Peter

[Francesco Agosti]

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

Francesco

[PHoll]

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

SCB_CleanInvalidateDCache();

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/STM32CubeMX.app/Contents/Resources/db/templates .

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.

Peter

[WBOUG]

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,

Wael

[kold]

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.

[FRain]

This is MVP of the year. thanks for sharing

[Piranha]

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:

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