• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 3011 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

"TCP: Retransmit Timeout" happens sometimes in my application

Jianyi Bao
Expert 2220 points

Hi,
I am using
1. TivaC1294NCPDT
2. tirtos_tivac_2_00_01_23
3. bios_6_40_01_15
4. ndk_2_23_01_01
5. TivaWare_C_Series-2.1.0.12573c
6. CCSv6.

My application is based on TCP socket example. Sometime I can see the following log print via UART:

22:48:57.684  Retransmit Timeout
14407.300 TCP: Retransmit Timeout
14415.400 TCP: Retransmit Timeout
14423.400 TCP: Retransmit Timeout
15202.900 TCP: Retransmit Timeout
15356.100 TCP: Retransmit Timeout
15990.200 TCP: Retransmit Timeout
15996.300 TCP: Retransmit Timeout
16005.800 TCP: Retransmit Timeout
16243.300 TCP: Retransmit Timeout
16463.200 TCP: Retransmit Timeout
16906.700 TCP: Retransmit Timeout
17487.400 TCP: Retransmit Timeout
17495.400 TCP: Retransmit Timeout
17518.300 TCP: Retransmit Timeout
17521.600 TCP: Retransmit Timeout
17528.200 TCP: Retransmit Timeout
17536.500 TCP: Retransmit Timeout
17554.300 TCP: Retransmit Timeout
17562.300 TCP: Retransmit Timeout
17931.000 TCP: Retransmit Timeout
17944.400 TCP: Retransmit Timeout
18643.300 TCP: Retransmit Timeout
18657.500 TCP: Retransmit Timeout
19132.700 TCP: Retransmit Timeout


myErrorHook called:
unused=0
Error_Data.arg=0x2002e188
Error_Id=0x0f330000
msg=E_stackOverflow: Task 0x%x stack overflow.
file= 
line=378

xdc.runtime.Error.raise: terminating execution

I am using IPv4.
"myErrorHook" is the hook function I defined which will be called when an error is raised. I guess "stack overflow" is the result of the previous errors.
Also, the cfg file of the project is attached.

Could anybody give me some hint what I shall do to solve this issue? Does a upgrade to new RTOS version solve it?
Thank you very much.

3108.APmain.cfg

  • 0
    Expert 2220 points

    Hi

      Anybody has any suggestions?

  • 0 in reply to Jianyi Bao
    TI__Mastermind 21645 points
    Hi Jianyi,

    TCP retransmit timeout can happen due to several reasons. It can happen if the network is busy or if the TCP packet got corrupted. How frequently do you see this timeout msg ?

    I reviewed the cfg file you shared and it looks like the stack size of your network tasks is very small. The NDK user guide recommends tasks doing TCP based communications should have a minimum stack size of 4096. You should increase the stack sizes for your network tasks.

    After updating the stack size, if you still see a stack overflow, you can look at the detailed task view in ROV and check which task's stack is overflowing.

    Best,
    Ashish
  • 0 in reply to Ashish Kapania
    Expert 2220 points

    Hi, Ashish
    I did two tests:
    1. Change NDP stack size to 5120, and the stack size of some other tasks that call NDK related functions (such as listen/recv/send) to 4096, and the issue still happens. However, when it happenes, the target will not reset. Before these changes, it will reset after this issues is seen. But I have enabled the watchdog. I will do more tests to see why it won't reset.
    2. Change all other tasks' stack size to 4096, and it seems that the issue disappears. So maybe the stack size of some tasks is too small. The attached is the final cfg file. Would you please review it to see whether there is still potential settting errors?

    Thanks2766.APmain.cfg

  • 0 in reply to Jianyi Bao
    TI__Genius 11600 points
    Hi Ashish.
    Could you kindly give a little comments on expaining above question? Thanks a lot!
  • 0 in reply to Jianyi Bao
    TI__Mastermind 21645 points

    Hi Jianyi,

    Jianyi Bao said:

    2. Change all other tasks' stack size to 4096, and it seems that the issue disappears. So maybe the stack size of some tasks is too small. The attached is the final cfg file. Would you please review it to see whether there is still potential settting errors?

    Your cfg file looks good.

    Jianyi Bao said:

    1. Change NDP stack size to 5120, and the stack size of some other tasks that call NDK related functions (such as listen/recv/send) to 4096, and the issue still happens. However, when it happenes, the target will not reset. Before these changes, it will reset after this issues is seen. But I have enabled the watchdog. I will do more tests to see why it won't reset.

    It is hard to guess what might be causing the re-transmit timeout. The problem may not necessarily be with the target. Can you describe your setup in detail ?

    Best,

    Ashish