2024-07-29 01:01 AM - edited 2024-08-04 10:25 PM
Hi Team,
I am using STM32F7 nucleo board, CUBEMX version 6.10, FREERTOS CMSIS V2, LAN8742 Eth driver. I am working with LWIP stack FULLDUPLEX 100Mbps configuration.
configured MCU as a server and re-establish communication in LWIP default thread.
1. case 1: Ethernet communication is working fine if I communicate every 50msec. (transmitting/receiving 250 bytes)
2. case 2: i. If I transmit and receive every 10msec, after several reconnection(removing ethernet cable and connecting it again) ethernet communication got lost, but all other functionalities are working(other threads).
ii. In this case tried ethernet cable plug out and plug in Link up and link down is detecting but communication not established, Ethernet communication re-established only after MCU reset.
iii. I tried debugging..but i didn't got any soln
So anyone can help me and give me some tips to solve this problem.
2024-07-31 05:14 AM
Hello @lavanya ,
Ensure that the LwIP configuration is optimized for your use case. For example, increasing the memory size reserved for RX_PBUF in ethernetif.c
can help in handling mass UDP data using LWIP_MEMPOOL_DECLARE() for example.
Make sure to populate the callback for handling the link down status ethernet_link_status_updated()
and add it using netif_set_link_callback() function for proper handling of link down scenario.
also make sure that you check for the link before proceeding as shown below in MX Lwip init :
if (netif_is_link_up(&gnetif))
{
/* When the netif is fully configured this function must be called */
netif_set_up(&gnetif);
}
else
{
/* When the netif link is down this function must be called */
netif_set_down(&gnetif);
}
Also make sure to allocate the proper stack size for the thread handling the communication with Ethernet and dynamically freeing the poll after each transmission maybe make it 2048 or more rather thant the default 1024 stack size.
Regards
2024-08-02 06:09 AM
Hi, @STea thank you for response,
I tried above changes but it's not working.
case 1: Whenever I unplug and replug again Eth default thread(where we init LWIP),is getting callled,
here i called lwip accept to accept new connection and close previous one.
this case Eth communication working properly.
But after 5,6 times plug in and plug out Eth default thread is not called and connection lost.
I am new to this topic,
May I know how eth default thread will get trigged.? ..as far as i only know it will get called if new connection req came.
2024-08-05 03:41 AM
Hello @lavanya ,
could you check the status of the link and a dump of PHY registers to check the link status after this problem occurs?
check the following regs:
MACCR, MACMIIAR, MACMIIDR, DMASR, DMACHTDR, DMACHRDR, DMACHTBAR, DMACHRBAR, MMCTGFCR
check the result of this function when the problem occurs:
2024-08-05 05:45 AM - edited 2024-08-08 12:45 AM
Hi, @STea thank you for response,
Here, I have attached ethernetif.c file
I checked PHYLink status in stuck case it was 2. i.e.(LAN8742_STATUS_100MBITS_FULLDUPLEX)
register status in stucked state
while debugging I observed following things,
I have 3 threads :-- 1. Establish Eth connection having Highest priority with osDelay 1. 2. Receive Lwip req and transmit (Above Normal) 3. Application task (Normal).
1. My task 2 (Lwip Tx/Rx) was getting blocked after few plugin and plug out eth cable.But ping is working, As I was not getting any request from slave I replugged Eth cable again.
2.After Replug it tried for reconnection now Eth communication stucked, Continuously Eth Err callback triggered.
Ping not Working Both Task1 and Task2 not triggering
kindly refer to these two files ethernetif.c and freertos.c is attached below
Thank you,
I appreciate guidance on this topic and give me some tips to solve this problem.
2024-08-14 07:15 AM
Hello @lavanya ,
Sorry for the delayed response, after giving it some thought it can be related to CMSIS v2 which may cause this misbehavior with Lwip as reported in this thread Re: STM32F746 LWIP + FreeRTOS CMSIS V2 - STMicroelectronics Community
could you test with CMSIS v1 and confirm if this solves your issue.
the issue discussed in the above thread is currently under investigation. ticket number 188613(for internal reference only).
Regards