WiFi connection lost after time

[Sailing_Nut]

I have an application where I wait for the chip to connect to an access point, then I send a UDP broadcast packet on port 1900. After that I just listen for packets on port 1900. At some point the chip stop receiving packets and it also becomes unresponsive to ping requests. Here is a snippet of how I am receiving packets:

Code: Select all

    UDPSocket sock;
    Endpoint client;
   
    int rc = sock.bind(SSDP_PORT);
    if(rc == 0)
    {
        //pc.printf("Waiting for SSDP M-SEARCH\r\n");
        int n = sock.receiveFrom(client, search, sizeof(search));
        pc.printf("Packet count = %i\r", cnt++);
        sock.close();
        return;
    }
    else
    {
        pc.printf("Error '%i' binding to SSDP port\r\n");
    }
    sock.close();



I believe that it is probably some mistake on my part in how I am dealing with the CC3000 chip but I have been unable to find anything in the documentation.

Thanks in advance for help on this!

[Carl-SolderSplash]

Hi,

Will try to find some time to look at this for you, please be do bear with me though, I'm currently working like crazy to delivery a project for a client.

[Carl-SolderSplash]

Hi,

What firmware version are you using? TI have released an update that apparently fixes a few issue in the module that may have stopped it responding to arp requests (stopping you from pinging it) viewtopic.php?f=15&t=97 (Please note this is still being tested)

Also, We have a new UDP demo here that listens for UDP messages and sends them. Which might be worth trying/comparing with your code.

http://mbed.org/users/SolderSplashLabs/ ... i/Homepage

Just one last thought, if you loose connection you may have to forget the sockets you have open and open new ones. I shall investigate that for you.

[Sailing_Nut]

Hi,

What firmware version are you using? TI have released an update that apparently fixes a few issue in the module that may have stopped it responding to arp requests (stopping you from pinging it) viewtopic.php?f=15&t=97 (Please note this is still being tested)

I was having the problem with the original firmware and then I updated to the 1.28 firmware and the problem is also present in that version as well.

Also, We have a new UDP demo here that listens for UDP messages and sends them. Which might be worth trying/comparing with your code.

http://mbed.org/users/SolderSplashLabs/ ... i/Homepage

Just one last thought, if you loose connection you may have to forget the sockets you have open and open new ones. I shall investigate that for you.

My code is using the blocking call presently. I will update it to use the non-blocking strategy that you are using and see if that makes an improvement. I'll post results as soon as I have them.

[Sailing_Nut]

Carl,

It seems to crash much more quickly with the non-blocking code. In 5 tests the most I have seen it receive is 3 packets. With the blocking code I had seen as high as in the 20's.

One interesting thing that I have seen is that it seems to respond to pings for a while (several seconds) after it stops receiving the UDP packets. But it does eventually stop responding to pings.

Let me know if you find anything or have anything else that I should try.

Thanks!

Tim

[Carl-SolderSplash]

Hrmm,

I've had the current udp mbed example running for two days without an issue.

Did you run the example as is?

[Sailing_Nut]

I ran my hang test converted to use non-blocking UDP reads.

My example waits for SSDP messages on port 1900 and just sends a serial message when it gets one. I'll try your code as is except I'll switch to port 1900 for listening for traffic.

[Sailing_Nut]

Carl,

I ran your UDP demo and changed the port to 1900. It hung not too long after receiving it's 1st UDP message. After the receive, it sent 2 packets then the . characters stopped printing to the serial terminal (I'm using Terra Term) then shortly after that it stopped responding to pings.

[Carl-SolderSplash]

How large is the packet that you are sending?

Fired up mine before going to bed and have found a large packet size can cause a hangup.

EDIT : Which is solved by increasing the CC3000 library CC3000_MAXIMAL_RX_SIZE define. in cc3000_common.h change it to :
#define CC3000_MAXIMAL_RX_SIZE (1519 + 1)

I can now spam it with UDP messages of 1.4k in size and it's fine, messages over 1.5k are ignored by the module as it doesn't support fragmentation.

[Sailing_Nut]

It may be the packet size. I'm just receiving SSDP traffic on my network. I seem to remember some large packets in the Wireshark traces. I'll re test and see if I can correlate it to a large packet.

Thanks!