STM32F4 ETHERNET RECEIVE ISSUE WITH LARGE PACKET

[MGOEL.1]

HI

I am using stm32f429 microcontroller for receiving 14000 byte packet continuously in TCP in Raw tcp.I am using LWIP 2.1.2 version for this .My packet gets received one or two times sometimes continuously receiving 14000 byte packet i have choosen underneath setting for lwip(out of 20 times one time it works flawlessly without fail)

• PBUF_POOL_BUFSIZE:1460
• TCP_WND: Four times the TCP_MSS would be:TCP_WND = 4 * 1460 = 5840 bytes
• TCP_SND_BUF:   5840 
• MEM_SIZE: MEM_SIZE = 20 * 1500 = 30000 bytes
• PBUF_POOL_SIZE: PBUF_POOL_SIZE = 20
• i have attached my project file as attachment for review
• Kindly help to identify the potential issue why receive packets gets stopped in between My microcontroller doesn't hang
• I have checked with wireshark also but it shows TCP_window full i have increased TCP_window to 28500 still same result
• Kindly help on the same I am trying to figure it out for past several days almost stuck now

[STea]

Hello @MGOEL.1 ,

just trying to reformulate your issue to make sure I get you right.
you have a software implementation of Lwip stack running on STM32F4 MCU and you are trying to receive 14000bytes (14kb) TCP packet but with your current configuration it is working inconsistently (sometimes working well meaning receiving all data and sometimes not). please confirm these statements if it is the case and elaborate more if not.

just have few other points to ask regarding your environment setup. how are you generating the 14000byte of data, which tool or script on your computer, on which OS, and how are you connecting your board and computer via Ethernet is it directly or over a switch or via a router ...
Regards

 

[MGOEL.1]

sometimes i am able to receive full packet of 14000 bytes sometimes it breaks in between.like after 7000 bytes (tcp raw lwip ,stm32f429vet6)or more it will stop receiving but stm32 pings and udp is also working at that time

But whenever i am using hercules to send 1024(last limit to send) bytes packet then i am able to send every time

I have checked in wireshark as the packet size increases ,retransmit of packet starts and then the problem arises

I am using our own software to send 14000 bytes which works fine I have checked this software with other end at computer. I am connecting stm32 with software( windows based developed on visual basic) through ethernet cable directly.STM32 being client 192.168.0.11 and Computer software being server 192.168.0.253 port 25000 tcp

Is there any modification in LWIP stack parameters needs to be done?

Or Any Reception point we are missing Kindly Help on the same. 

 

[MGOEL.1]

please find screen shot of packets being send as atatchemnt initially it receives perfectly some packet after that retransmission occurs as seen from wireshark screenshot now i hv used packetsender standard tool to send packets in order to explain my issue properly packets are received but very late in case packet is large microcontroller is never hanged i am sending some bytes through pachetsender so that are received as i hv made one u16 variable datasrno to count the no. of bytes received

Please HELP WE ARE EAGER TO RESOLVE THIS ISSUE ASAP.

THANKS IN ADVANCE 

[MGOEL.1]

@Andrew Neil @STea I am only interested in posting issue as my private message limit was reached Request you to kindly look into our problem. Thanks in advance

[STea]

Helllo @MGOEL.1 ,

make sure you are using the lated version of cube Firmware as there was a bug reported related to V1.27
[ETH] fix constant receive buffer size by DedkovArtem · Pull Request #119 · STMicroelectronics/STM32CubeF4 (github.com)
Regards

[MGOEL.1]

Hello@@STea

Thanks for reply

I have checked version it is updated and #define ETH_RX_BUF_SIZE 1536 seems ok

Issue still remains unsolved still i am finding solution

Thanks

Regards

 

 

[Pavel A.]

Do you understand that TCP packet this big will be fragmented by the LwIP library to fragments that fit into the MTU size, which in turn is limited by L2 (ethernet) packet size?  If such packets do not work, look at the fragmentation/reassembly issues. Or - simpler - as TCP is a stream protocol, just send the large content in smaller TCP packets that do not need fragmentation. Break the large data in your application. Be happy.