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.

AM335x Industrial SDK1.1.0.4 NDK and phy link down

Other Parts Discussed in Thread: AM3352

Hi,

     We are using a AM3352,  SYS/BIOS 6.35.4.50 and NDK 2.23.2.03 and had a question about having a Ethernet link down condition while threads are processing UDP packets. Our initial plan is to have several threads waiting on separate UDP ports to process the incoming packets. If during the packet processing the link goes down how is this error handled. We understand the cpsw3g_Update_Phystatus() will be called and have looked in the NDK documentation for examples, but don't see connection from the phy link going down and a error condition in the application code handling the packets on the socket side. Are their any better examples of this?


Thanks,

     John C.

  • Let me ask this a little differently. For a server socket we create() it, then bind() to it. Then you wait to accept() a connection and once made, you transfer packets (send() and recv()). If the physical link were to go down while we are transferring packets, what is the proper way to recover from this? If the link goes down during sending or receiving of packets, do you close the connection and socket or just the connection?

    Thanks,

         John C.

  • John,

    Good question.  If you are in the middle of a send() call, which is transferring a large amount of data, and then unplug the cable in the middle of such a transfer, I would expect the send call to return -1, with an error code of either "EHOSTUNREACH" or "ETIMEDOUT".

    It's been a while since I've tried that so I can't remember which.  But, if I remember correctly, you can "quickly" unplug the cable and re-plug it, and that should handle automatically. But if you unplug for longer, I think your send call will return with one of the above errors.  I think what you would need to do here is to write some code to handle this in your application (that's sending/receiving data).

    For example, if you detect a -1 return from send() along with one of these error codes, you could assume that the cable's been unplugged, and then wait for it to be plugged back in again.  This could be done with a Task_sleep, but ideally you'd want to pend on the actual interrupt from the hardware (that occurs when the cable is plugged in).  I think there was another API that you and Vinesh were discussing in another thread which may give you that functionality.  So, in that case, you could wait until "hearing back from the hardware" and then try to pick up the transfers where they left off.

    (Additionally, in NDK 2.24 we've added link detection support, which can call a user defined callback function when the link goes up/down.  This would be an ideal place to post a semaphore that you would be waiting on in your app code.  But, this new feature requires support at the driver level, and also given that you're having build issues with NDK 2.24, you might not want to go this route yet.  But wanted to make sure you were aware that it's been made available).

    Of course, if the cable was unplugged for too long, the other host (who's receiving data from your sends) may have already timed out and closed down its socket.  In that case, you would have to initiate a new transfer, and probably wouldn't be able to pick back up on the current one.

    Steve