STM32H723ZG Ethernet not responding to ping (No RTOS)

[max67]

I am working with the STM32H723ZG and trying to implement Ethernet communication without using an RTOS using LWIP(TCP/IP) 

Setup Details:

• Board: NUCLEO-H723ZG

• IDE: STM32CubeIDE v1.19.0

• Ethernet stack: LwIP

• PHY interface: RMII

• Flashing tool: ST-LINK (onboard)

• Test performed: Ping test from PC

Observed behavior:

• The Ethernet port LEDs (orange and green) remain solid ON after connecting the Ethernet cable.

• Ping is failing continuously, I got (Destination host unreachable) error.

Troubleshoot taken:

• Checked with multiple Ethernet cables to ensure cable isn't a problem. 

• I'm using static Ip and checked the Ip is correct in lwip.c while flashing the board.

• Rebuilt and reflashed the project multiple times.

After all this still I can't ping the board.

Assistance required :

• is there is any problem in cache coherency in the code?
• Kindly check with the MPU unit configuration and let me know is there is any issue?

 

I'm providing my Project file below

Any guidance or working minimal examples for STM32H7 Ethernet (without RTOS) would be greatly appreciated.

[Pavel A.]

Build and run this example  (change the MAC and IP addresses per your setup) :

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Projects/NUCLEO-H723ZG/Applications/LwIP/LwIP_UDP_Echo_Server/

It should work.

Compare with your project and find differences in the ETH config.

 

 

[STackPointer64]

Hello @max67, and welcome to ST Community!

I have attached a Baremetal LwIP example below for you to review and use as a foundation for your project. Please let me know if it works for you or if you need any further assistance.

Best regards,

[max67]

 Hello, @STackPointer64 @Pavel A. 

I went through the LwIP_UDP_Echo_Server code.

      From the code you provide I face this problem:

      I can be able to ping it when I flash it once and if I rebuild the project and flash it once again 
it goes into hard fault error. I don't know why?
      I double checked the Ip address and no fault in that 
      I checked it with another PC after the one-time flash and that is also not pinging.    

     If I disconnect and connect the power to the board and that time also, I can't be able to ping. 

     Below is the package which I'm using.

[STackPointer64]

Hello @max67,

After reviewing your project, I believe the only issue preventing it from working properly is that you mistakenly enabled the Ethernet global interrupt in the Ethernet settings. If you disable it, it should function correctly. Please do so and let me know whether it works.

Best regards, 

[max67]

Hello @STackPointer64,

       As you said, I did disable the Ethernet interrupt and build the project. I checked the Ip address and try to ping it but still can't ping it. I still got destination host unreachable error when I try to ping.
Is there is any working code for it, could you please provide it.
is there is anything to change anything in the code.

[max67]

Hello @STackPointer64 , 

Sorry for the delayed reply. I flashed the file you given it works good at first but if I rebuild it and flash it again, it is not pinging, some file is not generating while I rebuild it and in the first time flashing it is not working after the power cycle.
please check with the last updated project file and let me know what's the issue.

Thank you,

[STackPointer64]

Hello @max67,

That is rather unusual, as I tested the project and it worked before I sent it. Have you tried opening the project in a new STM32CubeIDE workspace? Could you try rebuilding the attached project, make sure that it does not work, compress it, and attach it to this thread so I can compare what changed between compilations? Also, try inspecting the network traffic using Wireshark when the board is plugged in to see whether an ARP announcement is being sent. Try changing the IP address and rebuilding to see if it is related to a network policy issue.

Best regards,

[Pavel A.]

>  and in the first time flashing it is not working after the power cycle.

Hmm.. this hints to the PHY reset issue?