TCP IP problem using LWIP RAW API in STM32F429ZI

[joseph05]

I am developing a terminal device that performs serial communication and Ethernet communication using stm32f429zit6. TCP IP communication is performed between this terminal device and the server, and lwip raw API is being used for TCP IP communication. When this terminal device starts Ethernet communication with the server, it operates normally at the beginning, but then retransmission occurs from the server, communication is cut off, and the software operation of the terminal device stops. From what we have analyzed so far, it seems that retransmission occurs when the terminal device receives a packet from the server and gives an ACK signal late. Is there a way to improve this in the terminal device?

The log below is the Ethernet communication packet log between the server and the terminal device. Here, 192.168.0.11 is the IP number of the server and 192.168.0.210 is the IP number of the terminal device.

 

 

[Pavel A.]

>  From what we have analyzed so far, it seems that retransmission occurs when the terminal device receives a packet from the server and gives an ACK signal late.

Hmm... Could it be that a problem in the STM32 firmware occurred earlier, and it caused the timeout and retransmissions? the firmware sometimes manages to recover but finally fails? So it looks for me.  

> Is there a way to improve this in the terminal device?

Try debugging the firmware, or find somebody who can do this for you.

[joseph05]

The terminal device has Ethernet communication function and serial communication function. Data received from serial communication is always transmitted to the server at 200 bytes per second, while other data is received from the server at 1-second intervals. If only Ethernet communication is activated on the terminal device, there is no problem with communication, but if serial communication is added, Communication. problems arise where communication is lost and the software freezes.

Below are the Key Options items in the LWIP setting menu. The current value is using the default value, but I would like to get advice on whether the values ​​below need to be modified to improve the communication problem.

[Pavel A.]

If these parameters work for you without the serial communication, they are unlikely to need change. Try to increase the stack size.

[joseph05]

The terminal device uses serial communication functions along with Ethernet communication. Dynamic memory is used for serial communication, and I guess that the operation related to dynamic memory allocation and release affects the terminal device's stopping. Additional testing is needed, so the content will be updated after work.

[Pavel A.]

There was a belief (or opinion) that dynamic memory allocation and embedded don't play ball together. Still makes certain sense today.

[Johi · Accepted solution]

Maybe it is agood idea to check the hypothesis of the dynamic memory allocation by the serial part first.

Therefor you could build a small memory manager based on a static array. Or even replace the dynamic part by a static part. This could point you in the right direction.

[joseph05]

Dear Johi, Thank you again for your advice. I used dynamic memory within the method for serial communication functionality. Dynamic memory allocation and deallocation within the method proceeded normally, but there was a problem with this function, and the device stopped 10 minutes after it was turned on. After many attempts, I resolved the problem of the device stopping due to this reason after using static memory (array) instead of using dynamic memory.

[LCE]

I had this TCP retransmission problem because the PHY was set up as 100M / full duplex, but due to reading the wrong PHY register after auto-negotiation the STM32 MAC was set up as 100M / half duplex. So maybe check that also.