STM32H563RGT6 with LAN8742A phy

[aravindpv]

Hi as part of my project I am trying to integrate the mentioned parts in subject to control modbus eth relay over tcpip.

What I have done so far.

1. Integrated Lan chip driver to stm32 library and initalization done.

2. Integrated LwIP stack from online resources and confirmed LwIP integration succeeded. (Since i'm using STM32H563RGT6 MCU and it doesnt have inbuilt LwIP stack with in it).

3. Initially tried to establish a connection with my PC and try a ping test.

4. I'm facing ARP Resolution initally but somehow it resolved and now i can find my MCU ip and mac address on my PC, but still ping is not reachable.

5. My POV is that if its capable of handling etherent packets then i can start work on with modbus packets to trigger the relay module.

Pls help me with this case...
 

 

[STackPointer64]

Hello @aravindpv and welcome to ST community,

To better understand and assist you with this issue, could you attach your STM32CubeMX configuration (.ioc file) so i can review your configuration and reproduce the problem.

Best regards,

[aravindpv]

Hi thanks for the reply @STackPointer64 . Please find the details below

this is the IOC view and i uploaded the file as well.
1. I am able to build the integrated LwIP stack successfully
2. IP assignment working properly
3. ARP resolved and able to find the device PC's ARP list.
4. ping isn't getting reply, but not showing not reachable as well just request time out.
5. I can see the traffic on wireshark.
6. I am planning to built a tcp client on top of it for my project project purpose, so I expect the ping establishment is required.

[STackPointer64]

Hello @aravindpv,

After analyzing your STM32CubeMX configuration, I suggest increasing your thread stack size to at least 256 words instead of 128. If the issue persists, consider adding an MPU configuration to reduce the risk of memory corruption. Additionally, I recommend reviewing the projects in the repository linked below to compare configurations. Once the ping works, you can take inspiration from the TCP client implementation for your Modbus project.

• LwIP-H563

Best regards,

 

[STackPointer64]

Hello @aravindpv,

Do you have any updates regarding your problem? Were you able to resolve it?

Best regards,

[aravindpv]

@STackPointer64  Hi ,
i updated the stack size as you mentioned
osThreadId_t defaultTaskHandle;
const osThreadAttr_t defaultTask_attributes = {
.name = "defaultTask",
.priority = (osPriority_t) osPriorityNormal,
.stack_size = 256 * 4
};

Still there is no ping.

[STackPointer64]

Have you tried comparing your project files with the working example I mentioned in my second reply? Doing so will help you pinpoint the issue in your project.

[STackPointer64]

Could you please attach your project so I can review it? If the project is private, feel free to send it to me privately.

[aravindpv]

@STackPointer64 
Hi please find the attachment

[STackPointer64]

Thanks for sharing your project details, @aravindpv. From my review, here are a few points to consider:

• In app_freertos.c, the linker file is missing LwIP section configurations, and the stack size is set to 256 words × 4, which may be insufficient. Also, using LwIP polling functions (like ethernetif_input(...)) inside the default task’s while loop is incorrect and won’t work. You should terminate the init thread with osThreadTerminate instead.

• In ethernetif.c, several essential functions are missing, including LwIP and callback functions that handle semaphores and other tasks. Additionally, the MAC address is commented out, so no MAC is assigned as the config struct used by LwIP.

• The project also lacks an application layer such as a UDP server, which is necessary to ping the board and test connectivity.

To move forward, you have two options:

1. Compare your project with a working example that uses FreeRTOS. Note that the LwIP_TCP_ECHO_SERVER example does not implement FreeRTOS, so configurations differ between RTOS and non-RTOS setups.

2. I recommend starting from the LwIP_UDPTCP_Echo_Server_Netconn_RTOS project and adapting only chip-specific parts like GPIO configuration, ETH MSP init/deinit, clock setup, linker file (ensuring memory sections are respected), and LwIP configurations (memory size, stack size, etc.).

The choice is yours, and I will support you along the way until you have a working example.

[aravindpv]

Hi @STackPointer64 , I was busy with some other works for the last week.
As you suggested I used the LwIP_UDPTCP_Echo_Server_Netconn_RTOS and the integration was successful.

1.  I used the stack size 512*4
2. As you mentioned using ethernetif_input inside the for(;;) loop, i expect it to do polling and i feel its correct for my requirement.
3. I followed this  https://community.st.com/t5/stm32-mcus/how-to-use-the-lwip-ethernet-middleware-on-the-stm32h5-series/ta-p/691100#:~:text=This%20article%20presents%20a%20tutorial%20on%20manually%20importing,STM32H5%20microcontroller%20series%20without%20relying%20on%20the%20STM32CubeMX. for developement
4. Present condition is that the normal ping from PC isnt working, it showing request timed out. But the ARP resolution is working and i can see th log on uart (Pls refer the screenshots attached)
   
   
5. But nping from works well and getting response (Pls refer the screenshots attached)
6. I can see the traffic on wireshark aswell
7. Tried turning off the firewall etc..

pls help me with this case..

 

 

 

[aravindpv]

@STackPointer64 
please see the attached file.
I am not passin after netconn_accept. i have tried running a client from windows PC using telnet and it exits with timeout.

[aravindpv]

Hi @STackPointer64 

Hi the issue is resolved, established ping from pc to mcu
the issue is with implementation of lwipopts.h

 

 

[STackPointer64]

Hello @aravindpv,

I’m glad to hear that you resolved your issue. I recommend adding the LwIP memory section in the linker file, as it was missing in your project. Also, consider sharing the specific issues you encountered in the lwipopts.h file that caused your program to malfunction. This will help future users avoid the same mistakes. Thank you for your contribution.

Best regards,