TM4C+nonOS+lwip timeout problem

Hi Caffein,
We are not experts on the LwIP so not sure why a shorter timer interval will cause a problem. Have you tried with other intervals? You drastically change from 250 to 5ms. I will suggest you try with different intervals and find out at which minimum interval the communication still works. By doing this we can kind of isolate if the problem is more eccentric or hardware. I will suggest you also contact LwIP for support.

This post may contain something helpful because it discusses lwIP on TM4C129ENCPDT without RTOS:

high12noon.neocities.org/lwip_polled_tm4c129.html

Hi twelve12pm,

 Thanks a lot for sharing the article. I learn from it too.

Hi twelve12pm,

Thank you for sharing the experience, let me learn a lot.
Will you move lwIPEthernetIntHandler() to SUPERLOOP for polling, the main purpose is to get better performance?

regards,

Caffein

Hi Charles,

Ok, thank you for your advice.

regards,

Caffein

Caffein Lin said:

Hi twelve12pm,

Thank you for sharing the experience, let me learn a lot.
Will you move lwIPEthernetIntHandler() to SUPERLOOP for polling, the main purpose is to get better performance?

regards,

Caffein

Hello Caffein

The main purpose is to get better performance in other parts of the system, which are time critical. Priority of Ethernet service is less important in our application.

Hope this helps.

Hi Caffein,
Have you tried to find out at what interval did the problem starts to occur? It seems to me you are running into some bottleneck.

Hi Charles,

Sorry for the late reply.
Because it happens from time to time, sometimes it takes a day or two to happen before the timeout occurs.
Currently the board is doing network communication testing.
After the test is over, I will go to find out the time interval at which the problem occurred.

Thanks.

regards,

Caffein

HI Caffein,

If you enable LWIIP debug UARTprtintf() messages (lwipopts.h) for TCP you will see a (Wait-Timeout) may occur sometimes during faster 5ms periods. It seems (lwiplib.c) also fails to handle OOSEQ timeout cleanup. I added call below to check condition LWIP seems to omit and slowed down timer once again. Out of sequence packets never get ACK response, TXD pbufs were once allocated. You can try to speed up (disable Nagle) for much faster transfers via Telnet and other RDP protocols, e.g. your client pcb pointer ->flags |= TF_NODELAY.

What seems to occur, no remote SYNC response relate to lost frames for allocated pbufs taken from memory pool. That may also cause dropped frames messages, we need to reclaim (pbuf=Null) memory space or eventually crash TCP stack. It was unclear if LWIP1.4.1 was performing the call to reclaim OOSEQ memory space but it seem perhaps not. At lest fewer wait timeout messages seem to occur after adding call below.

   /* Periodically check LWIP timeouts. Attempt to reclaim memory space
    * from queued out-of-sequence TCP segments.
    * Put an element back into its pool. Free OOSEQ queued PBUFs when
    * when the PBUF_POOL is empty, PBUF_CHECK_FREE_OOSEQ == 1 (pbuf.h) */ 
#if LWIP_TIMERS
    if((g_ui32LocalTimer - g_ui32LwipTimeoutTimer) >= MEMP_NUM_SYS_TIMEOUT)
    {
    	g_ui32LwipTimeoutTimer = g_ui32LocalTimer;
    	sys_check_timeouts();
    }
#endif

BTW my: TCP_TMR_INTERVAL=325ms

The GPTM 5ms interrupt increments LWIPTimer(5) polling semaphore @25ms. You can adjust number of desired periods (lwipopts.h) HOST_TMR_INTERVAL for TM4C129_HAL interrupt handler. I have two TCP stacks, LWIPTimer(5) 25ms interval works quite well. The LWIP timers are difficult to adjust but can be made to mesh into your higher application NVIC priorities by simple tweaks made to both intervals.

Hi BP101, 

Thank you for your reply. Regarding the call to sys_check_timeouts(), I saw that you have already explained in the article published by e2e that it has been added. After adding, the timeout effect is improved.
I will try this effect later on the advice to disable Nagle.

Thank you very much for your advice, because I saw on e2e that you published a lot of articles about tm4c129 + LWIP.

Thanks.

regards, 

Caffein

Hi BP101,

Regarding your TCP_TMR_INTERVAL = 325 millisecond setting, it seems that it takes a long time (100 milliseconds level) to send it out if there is data to send.
Do you have to call tcp_output() to make the data transfer immediately?
(Because my current application requires an immediate data response.)

I am still learning LWIP related technology. If I ask a question that is not OK, forgive me.

Thanks.

regards,

Caffein

Hi Caffein,
Thanks to BP101, I hope he is providing some guidance that is useful to you. I wonder if you had a chance to contact LwIP too? As we are not experts in the intricacy of LwIP, I believe they can provide some hints as to improving performance (i.e. reducing latency on the transfers) from the TCP stack point of view.

Charles Tsai said:

Hi Caffein,
Thanks to BP101, I hope he is providing some guidance that is useful to you. I wonder if you had a chance to contact LwIP too? As we are not experts in the intricacy of LwIP, I believe they can provide some hints as to improving performance (i.e. reducing latency on the transfers) from the TCP stack point of view.

Most likely the first thing the lwIP devs will tell you is that we need to update to the latest upstream lwIP, which is version 2.1.2. Then, performance improvements can be contributed back upstream. If we could create a TivaWare port of lwIP such that we can use stock (unmodified) upstream lwIP, then future updates of lwIP will not require additional work to use on TM4C.

Hi Caffein,

Try to disable the Nagle protocol in your Pbuf pointer used for tcpout() will speed packet rate via TM4C_129.c HAL TX descriptor DMA handling. Packets placed into a ring buffer should not take 100ms transfer out PHY.  The call to output ring buffer packets can also be invoked from the same LWIP timer in 5ms intervals. You can also set the priority of packet transfer in the TCP callback handler you specified to handle LWIP packet responses.

// Setup the TCP connection priority.
tcp_setprio(pcb, TCP_PRIO_MAX);

The call to send real time packets should only set Boolean switch for clients TXD handler & quickly exit. Let LWIP/HAL/DMA/PHY timers do the rest of the packet transport handling. Also EMAC0/PHY clock rate must be 25Mhz XTAL or TXD speed (Nagle delay) may be greatly impacted.  

Hi Twelve12pm and Charles:

thank you for your reply.
I used LWIP for the first time.
I really have a lot to learn.
I will reply to this topic if there is a solution or improvement.

regards,

Caffein