ARP requests not transmitted on STM32H735 with FreeRTOS and LWIP

[Legacy member]

Hello all,

I've spent several days trying to ping my STM32H735 discovery kit with FreeRTOS and LWIP, to no avail.
I've followed this tutorial as a starting point: https://community.st.com/t5/stm32-mcus/how-to-create-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308
I've also investigated on most of the issues mentioned here, without success: https://community.st.com/t5/embedded-software-mcus/how-to-make-ethernet-and-lwip-working-on-stm32/m-p/261456/thread-id/17638

After enabling logs and doing some debugging, I've confirmed that my board successfully receive the ARP request from my computer, etharp_raw sends a raw ARP packet and ethernet_output send a packet. All functions returns a success error code (i.e., 0), so everything is working fine according to the board, but I don't see any outcoming packet on Wireshark.

There is an errata for the STM32H72xx/73xx series, indicating that the ARP offload is not working:

ARP offload function not effective
Description
When the Target Protocol Address of a received ARP request packet matches the device IP address set in the
ETH_MACARPAR register, the source MAC address in the SHA field of the ARP request packet is compared with
the device MAC address in ETH_MACA0LR and ETH_MACA0HR registers (Address0), to filter out ARP packets
that are looping back.
Instead, a byte-swapped comparison is performed by the device. As a consequence, the packet is forwarded to
the application as a normal packet with no ARP indication in the packet status, and the device does not generate
an ARP response.
For example, with the Address0 set to 0x665544332211:
• If the SHA field of the received ARP packet is 0x665544332211, the ARP response is generated while it
should not.
• If the SHA field of the received ARP packet is 0x112233445566, the ARP response not is generated while it
should.
Workaround
Parse the received frame by software and send the ARP response if the source MAC address matches the
byte-swapped Address0.

But I'm not sure if that applies to my issue as the logs seems to indicate that the board sent the ARP response, even though it is not the case in the end. I also don't know how to and where the workaround should be applied.

Does someone have any idea on why the ARP response isn't transmitted, even though no error is thrown? Any hints on what I could try?

Thanks a lot for your help and advice!
Regards,
T

[Pavel A.]

A general advice is to test with a ready example before generating new project in CubeMX/IDE.

Examples are in the H7 cube library package and in this repo: https://github.com/stm32-hotspot/STM32H7-LwIP-Examples

Check in the lwip config header file whether the ARP offload is enabled. But, as you've noted, this should not affect transmit of the response.

[LCE]

So how is the ETH_MACARPAR register set (I don't use that register at all)?

Any bit in some register which enables the ARP offloading?

[Legacy member · Accepted solution]

Hi all,
I wanted to thank both of you for taking the time to reply to this thread.

I had indeed tried this example for the STM32H735 demo board: https://github.com/stm32-hotspot/STM32H7-LwIP-Examples/tree/main/STM32H735_Disco_ETH
I had the exact same issue however, the ARP request was well received and the H7 was telling that the ARP reply had been sent successfully, even though nothing was received on my computer according to Wireshark.
In this example the ARP offloading was enabled.

I tried to investigate at lower-level and look at the registers, to no avail.

In the end, I got a new and never used STM32H735 Discovery Kit and flashed the Disco_ETH example. After setting a static IP address, the ARP reply was received by my computer and I was able to ping the H7 successfully, without tinkering the code further.
So basically something was off in the hardware of my board, I don't know what, but using a brand new hardware solved my issue. There were some issues on the code of my own issue, but at least I got some hard faults and error codes to look at and I was able to solve them in a couple of hours.

So to conclude, even though it was mentioned on some ST forums threads that the ETH examples were not functional, as of 2023/06/29, the STM32H735_Disco_ETH example is working out of the box on a STM32H735 Discovery Kit. The LWIP ARP offloading option can be enabled without trouble.

Replacing the hardware and hoping it will fix everything often looks like a last resort option, but hey, sometimes it works!

Thanks again for your help.

T.