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.

CCS/AM3359: NDK UDP shutdown

Part Number: AM3359
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

I have a UDP program running on BBBlack and it transmits and receives fine, however, if the packet stop for a few mins and then restart it take ~ 10sec or so before packet start being transmit or it give the host down error code. There is not keep alive time for UDP, so why is the stack seemly shutdown?

  • Hi,

    Please clarify PRSDK, SYSBIOS, NDK version? Did you try the latest? What is the test application you run? How do you make the packet stop for a few minutes? By unplug the cable? Need you to provide the details for analysis.

    Regards, Eric

  • Hi Eric,

    I'm using the latest version CCS 9.1, NDK 3.60.013, BIOS 6.75.2, PDK 1.0.15... I have a windows based program that I wrote to send packets to the BBBlack and echo it back. I can stop the transmission of data a wait X number of second and then restart. Once restarted I watch Wireshark and see when the BBBlack response or create the NDK_EHOSTDOWN error code. No cable is disconnected.

    The test application is based on the BBBAm335Xproject. I've added code to create a socket, blinded it the local address and then connected to the remote computer.

    UDP_Config()

    {

        local_addr.sin_family = AF_INET;
        local_addr.sin_addr.s_addr = inet_addr("10.10.0.155");
        local_addr.sin_port = NDK_htons(16000);

        remote_addr.sin_family = AF_INET;
        remote_addr.sin_addr.s_addr = inet_addr("10.10.0.106");
        remote_addr.sin_port =  NDK_htons(1000);

         fdOpenSession( TaskSelf() );
         s = NDK_socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

        if (s == INVALID_SOCKET)
            NIMU_log("socket %d d\n", fdError());

        //local address
        err = NDK_bind(s, (struct sockaddr *)&local_addr, sizeof(local_addr));

        if(err<0)
             NIMU_log("Binding = %d\n", fdError());

        //remote address
         err = NDK_connect(s, (struct sockaddr *) &remote_addr, sizeof(remote_addr));
         UDP_SendMsg((char *) &Txbuffer,255);

        fdCloseSession (TaskSelf());

    }

    task check ND_recv and if there is data then send it back. Are socket option that need to be set?

    Thanks for your reply

    Rob

  • sorry forgot to add the receive code

            fdOpenSession( TaskSelf() );
            data = NDK_recv(s,(char *)&Rxbuffer, 1500,MSG_DONTWAIT);
            if (data > 0)
            {
                //NIMU_log("\nData received %d",data);
                UDP_SendMsg((char *) &Rxbuffer,data);
                memset(&Rxbuffer,0,sizeof(Rxbuffer));
            }
            fdCloseSession (TaskSelf());

    My understand is fdOpenSession and fdCloseSession must be before socket active is done, that seems to be the case - right?

  • Hi,

    Thanks for the info. From what I know, if i do ICMP ping the EVM, it responds. Then, I wait for a few minutes and ping again, I have the ping response right away. I don't have to wait for a few seconds. What is the difference for your UDP socket case?

    Regards, Eric

  • Hi,

    Even the ping hang and the kick back in.. Very weird.

  • It must be something with the socket init. If I just ping with /t it dies after 100 or so pings. I'm using cfg to config the stack

  • Hi,

    There are already existing CCS projects you can test the ping, I tried it for more than 20 minutes, the ping never fails. Note, I used NIMU_BasicExample_evmAM335x_armExampleproject on AM335x GP EVM, if you use BBB, then try NIMU_BasicExample_bbbAM335x_armExampleproject.

    Regards, Eric

  • Hi,

    That's the example i'm basing the code off of. The BBBlack stops responding to the ping after about 300 or so pings. looks like the stack is crashing? I'll rebuild lib and see if that help.. 

  • A thought, could auto negation cause this? 

  • Issue seems to be solve by rewrite the UDP task a little.

    Thanks Eric!