Need help to run Ethernet communication correctly with STM32H7 nucleo?

[Bilge]

 Is there anybody who can ran ethernet communication correctly with stm32h7 nucleo?

[brath]

hello everyone

im new stm32 im using stm32h743zi i want to send udp packet can anyone one suggest the exact procedure to send a udp packet using lwip

[Joerg Wagner]

I had a lot of trouble with H743 and sometimes I thought H stands for hobby,

so much time I had to spent with. After 1 year still no status quo to work professional.

You have to insert assembler code in the startup function to use RAM domain D3, hello? (Thanks to @Community member​ )

No IDE prepares the linker script to use Ethernet properly. Very high learning curve for someone who worked with other brands.

The differences in ethernetif.c from @Imen DAHMEN​  are not like "Hey there were important bugs fixed, now I'm sure it works.". It's more like "Okay, we switch off D-Cache and look what the customers are reporting". I wanted to develop a complex board with H743 but I'm so scared about this step. i.MX RT1064 has a linear memory layout for example. H7 has bridges no one knows how the routing works. For example: the reference manual RM0433 says on page 99 "Ethernet DMA can access SRAM4", I'm still not able to use it.

And why are there no CubeMX examples from ST? There were so many bugs in the past in this useful tool. When you work with this every day you would take more care of it. I wish ST the best for 2019, it lacks in software not hardware (except F76x version A).

[KR1]

Dear Imen,

I have updated the ethernet.c file in the STM32Cube_FW_H7_V1.3.0 LwIP example and I can assure you that the Ethernet connectivity problems still prevail.

I have complied the LwIP_HTTP_Server_Netconn_RTOS code using IAR ARM without adding any changes to the compiler/linker settings. After connecting the device to my local network, I ran a script that periodically issues a ping command to the development board. After running the script for an hour or so I begin getting time-outs that become ever so frequent as time passes. If I leave the script running the device eventually becomes unresponsive to pings (I begin to receive the "Destination host unreachable" response) and the OS (or one of the middlewares) seems to crash. For example, the behavior of the uplink-indicating LEDs becomes rather weird. If I physically disconnect the device from my switch LD2 (blue) turns off and LD3 (red) turns on, thus indicating that the device is not connected. If I reconnect the device back to my switch LD2 turn back on only after a minute or so (even though I get no activity from device – I monitor the device’s web activity using Wireshark).

Should I implement any changes to the compiler/linker setting, increase the stack/heap size, or choose a different development environment (e.g., SW4STM32)? Because the given changes to ethernet.c do not seem to improve the performance whatsoever.

[Joerg Wagner]

I created a project in CubeMX 5.0 from scratch.

The modified ethernetif.c was not used, just the

one created from CubeMX.

TCP, UDP and Ping work, tested it for 20 hours.

IDE's are SW32STM and TrueStudio.

[KR1]

A little update.

Following Joerg's advice I switched to SW32STM32. Surprisingly, the version compiled with the arm-gcc compiler (yet again, using the default compiler settings) seems to be somewhat more stable (although, still not perfect). I ran two consecutive tests, identical to ones described in my post above. Essentially, I was continually pinging the H7 devboard and parsing the out-coming response. I incremented my error count whenever I received a time-out or a "Destination host unreachable" response. The error accumulation results are presented in the graph below:

During the runtime, I received a time-out ever so often, but the device was operational nonetheless. After running for about 14 h on my first run and about 17 hours on my second run, one of the midlewares seemingly crashed. The the sharp rise in the accumulated error count graph indicates that a "Destination host unreachable" error was received each time that the device was pinged. I am attaching a zoomed-in version of the error accumulation graph just for clarity:

While 12+ hours of stable operation is a good endeavor, it is still not satisfactory for a device that is supposed to be connected to the network 24/7. I will run a few more tests (e.g., on an older version of the firmware and on the latest without modifying ethernetif.c, as suggested by Joerg) and I will present the results of my tests.

[Joerg Wagner]

Basically there should be no difference to TrueSTUDIO. I built a project in CubeMX 5.0 from scratch and compiled it with TrueSTUDIO. It runs for days without an error, TCP, UDP and ICMP.

You have to take care of the additional sections for ETH in the linker file and the right MPU config, regardless which IDE is used.

[KR1]

This is really weird. I tried to follow your suggestions but I did not have any luck. Truth be told, I was not able to get Ethernet running at all. I find this really odd because I can get it running without FreeRTOS. I have done it in the past, as desribd in https://community.st.com/s/question/0D50X00009nM9wPSAS/lwip-problems-from-code-generated-via-stm32cubemx-smt32h7 . I've redone all the steps on CubeMX 5.0 and this approach still seems to be operational (I did not run any long term test on it though). On the other hand, everything seems to go haywire if I enable FreeRTOS. I can reiterate the steps that I take to enable LwIP/FreeRTOS. They are, as follows:

1. Set the HCLK to 400 MHz (clocked from the HSI);
2. Enable the ETH peripheral, set it to RMII mode, and set ETH_TXD0 and ETH_TX_EN pins to PG13 and PG11 (others are mapped appropriately);
3. Set Very High Speed to all the pins (except PC1/ETH_MCD which always defaults to Low);
4. Enable the CPU ICache and DCache (under Cortex_M7 Configuration);
5. Enable the LWIP middleware;
6. Enable FreeRTOS;
7. Enable global Ethernet interrupt (with the priority of 5);
8. Select LAN8742/LAN8742 as the Driver_PHY (under LwIP>Platform Settings)
9. Enable ICMP (LWIP_BROADCAST_PING and LWIP_MULTICAST_PING in LwIP Key Options>IPMP Options).
10. Set stack/heap to, appropriately, 0x800/0x400;
11. Generate the code
12. Edit main.c by adding the MPU_Config function from https://community.st.com/s/article/FAQ-Ethernet-not-working-on-STM32H7x3 . I add a call to this function in the very beginning of my main();
13. Edit the linker file to partition the RAM from 0x24000000 to 0x2407FFFF;

As I’ve mentioned earlier, everything works if I skip step #6 and add the additional lines of code required for networking in the infinite while loop (see https://community.st.com/s/question/0D50X00009nM9wPSAS/lwip-problems-from-code-generated-via-stm32cubemx-smt32h7 ). I tried enabling MBEDTLS, but that did not seem to have any effect. Am I missing a crucial step, because all of this seems very bizarre?

[Joerg Wagner]

Please post your MPU_Config() and

the section of the linker file where the Ethernet descriptors are defined.

[KR1]

OK, I think I have actually found the problem. I retraced my steps and found an additional parameter change that I forgot to mention. In order to regain the IP address whenever the connection is lost, I had both LWIP_NETIF_API and LWIP_NETIF_LINK_CALLBACK enabled (both in LwIP->Key Options->Network Interfaces Options). Defaulting them back to a disabled state got the Ethernet running on H7. I will have find a way to get them running though, because I need the ability to reconnect/gain a a new IP address after a physical connection change or network failure.

[Joerg Wagner]

This can be done with the callback function:

void ethernetif_notify_conn_changed(struct netif *netif)
{
     ...
}