• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 903 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.

RTOS/TDA2E: Network application freezes after running some time.

Prasad Jondhale
Mastermind 27743 points
Part Number: TDA2E

Tool/software: TI-RTOS

Hello,

Tools used: TDA2xx EVM with NSP4_15 and  ndk_2_24_02_31

I am running VSDK network receive use-case with 1280x960 YUV422  data (frame size = 2,457,600bytes). After running use-case we see both PC application and use-case freezes with no error. On PC wireshark I see PC app trying to send packet again and again but not receiving ack from EVM. Sometimes after random time use-case resumes and network receive starts working but other times it freezes forever. 

The same use-case runs without any issue if we change frame to 1280x720 (frame size = 1,843,200)

  • 0
    TI__Mastermind 27743 points

    One more snapshot when failure occured but connection resumed after some time.

  • 0 in reply to Prasad Jondhale
    TI__Mastermind 30830 points
    I'll have to ask an NDK expert and get back to you.
  • 0
    TI__Mastermind 45025 points

    Hi Prasad,

    Can you please share the Wireshark capture file?  Actually I would like to see the capture files for both the working case (frame size = 1,843,200) and problem case (frame size = 2,457,600bytes).

    Also, which IP address is the NDK and which is the PC?  I think that .200 is the NDK and .201 is the PC, but please confirm.  I'm assuming this is true from here on.

    From the screen shot you provided, I can see that the PC is currently way ahead in its data sending vs the NDK in its data processing.  E.g. packet #87396 shows a sequence number of 80,301, which means that it's now sent that number of bytes.

    But, the NDK ACKs are way behind.  Packet #87418 shows that it has only ACK'd 21,901 bytes from the PC.  Furthermore, it seems that the NDK is immediately ACK-ing the retransmitted packets.  You can tell because the ACK number in packet 87418 increased by 1460 bytes (since the last ACK at #87395), which showed 20,441 bytes received. (the ACK tells you how many bytes have been RX'd, and the Seq number is how many have been sent).

    I can't explain why the NDK is so far behind in processing the data that has been sent at this point.  But it seems that for some reason, a number of packets may have been dropped (so they are being re-transmitted by the PC).

    Steve

  • 0 in reply to Steven Connell
    TI__Mastermind 27743 points

    Steve,

    Thanks for your reply.
    Your assumption is correct, NDK has IP address .200 and PC has .201

    I have shared wireshark logs via mail. Let me know your findings.