WiFi connection lost after time

[Carl-SolderSplash]

Super well hopefully this solves the issue.

You should be able to have smaller on chip buffers and not hang when large UDP message come in, so this points towards an mbed library bug. Something to add to my todo list.

[Carl-SolderSplash]

The real issue is that the applications buffer size is bigger than the CC3000 librarys SPI buffer.

UDP_RecvSocket.receiveFrom(client, (char *)UDP_RecvBuffer, UDP_RECV_BUF_LEN);

The receiveFrom call asks the library to fetch more bytes than the SPI buffer can handle. So increasing the SPI buffer fixes it, as would decreasing the UDP_RECV_BUF_LEN define to be less than the CC3000_RX_BUFFER_SIZE (Note the CC3000_RX_BUFFER_SIZE define includes protocol overhead of around 20 bytes)

[Sailing_Nut]

The real issue is that the applications buffer size is bigger than the CC3000 librarys SPI buffer.

UDP_RecvSocket.receiveFrom(client, (char *)UDP_RecvBuffer, UDP_RECV_BUF_LEN);

The receiveFrom call asks the library to fetch more bytes than the SPI buffer can handle. So increasing the SPI buffer fixes it, as would decreasing the UDP_RECV_BUF_LEN define to be less than the CC3000_RX_BUFFER_SIZE (Note the CC3000_RX_BUFFER_SIZE define includes protocol overhead of around 20 bytes)

So, I found that the definition of CC3000_RX_BUFFER_SIZE is in cc3000_common.h by the definition of CC3000_MAXIMAL_RX_SIZE which was defined to be 511 + 1.

I changed that to 1500 + 1 and I then changed my receive buffer in my code to 1500.

I am getting much better results but I still see that after a time it hangs.

My Wireshark trace shows that the maximum UDP packet that is ever sent to port 1900 is 1066 bytes on the wire (1024 bytes of actual UDP packet data), so I should not be exceeding the maximum size or MTU (so no fragmentation)

I know that in your explanation you said that there should be 20 bytes of space for SPI protocol overhead so I then changed the RX_BUFFER to 1520 + 1. With that setup the chip hangs on receiving the very first UDP packet and stop responding to pings as well.

I then set the RX_BUFFER to 1066 + 1 and my program buffer to 1024. I then re-ran my tests and this seems to be a more stable configuration but it crashed after 32 packets received and stopped responding to pings. I then ran the test again and it died after receiving 11 packets.

So either I mis-read what you were saying and did not properly apply the fix that you had in mind or there is still something wonky with the library code.

Please let me know if there is anything I can do to help out and try to find the problem!

[Carl-SolderSplash]

These are the values to use :

#define CC3000_MINIMAL_RX_SIZE (130 + 1)
#define CC3000_MAXIMAL_RX_SIZE (1519 + 1)

#define CC3000_MINIMAL_TX_SIZE (130 + 1)
#define CC3000_MAXIMAL_TX_SIZE (1519 + 1)

if you just change our UDP example app's port number :

const int UDP_LISTEN_PORT = 1900;

and the values above in cc3000_common.h what happens?

I've just re-read http://processors.wiki.ti.com/index.php ... onsumption, 1500 is the MTU but the actual maximum packet size is 1468 so your receiveFrom call should not send a value above this

Be sure to use the "Compile All" option in mbed too after making the change

Alternatively here is my compiled udp demo : http://www.soldersplash.com/docs/WifiDi ... t-1900.zip im using the latest patch level 1.28.

I seem to get bursts of 20 or so messages every 5-10 minutes from various devices on my network received on port 1900.

I do have a TV on the network though that dumps 20-30 udp messages on to the network with the tinyest gap between them, because this example polls for recv'd data my poll rate means I miss a couple of the messages. It doesnt hang though.

[Sailing_Nut]

So things have gone to hell here.

I re-ran the original UDP sample with the Rx port changed to 1900. I originally ran this test and it would lock up over time. My re-run showed that the CC3000 lost connection to the AP as evidenced by it starting to send "no connection" to the terminal after receiving a packet.

I thought that maybe there had been some signal interference so I tried to add my 2nd AP into the profiles using the smart config tool. That did not seem to be successful so I deleted the profiles and then attempted to add the AP. I now cannot add an AP to the profiles using Smart Config AND I can't connect to the AP by passing the AP name and PSK to the API.

So, I now hade a device that cannot communicate wirelessly at all!

[Carl-SolderSplash]

Oh Dear,

Sorry your having all of these issues,

My first thought would be to delete all profiles, but you have done that. My only other is to use the firmware update firmware again to re-flash it, this procedure clears down all of the cc3000 internal profiles.

If/when you've done this and it's connected again, can you use the supplied .bin above and report back. Let me know how it goes.
I started to add code to re-initialise the UDP port if the connection was lost but it's not finished. So if you hang after loosing the connection then thats something we can work on.

With a stable connection I have had that firmware listening on port 1900 for a few days now without issue.

[Sailing_Nut]

I reapplied the update and attempted to use smart config with the updater BIN file by issuing cc3000 smart but that did not seem to work. I was able to connect to my one AP using the manual connect, however the cc3000 does not like my other AP. It will not connect. I have tried WPA and WPA2 (my phone shows the AP as WPA/WPA2 PSK) and it will not connect.

Is there a way to read the stores profiles form the cc3000 with the updater bin file? I can't seem to find a list of the available cc3000 commands.

[Carl-SolderSplash]

It's good that you got it connected to something!

Reading profiles out is not something I've done, shall investigate to see it's possible.

Try
"cc3000 scan" that should list the AP's the module can see, which might be useful.

Also after a bit of googling, stopping the scan might help you connect, although these are reports might be for older cc3000 firmware. you can stop it with : "cc3000 startscan 0"

[Sailing_Nut]

I can't pin down exactly when this happened but I began trying the various commands that you gave me and now when I try the cc3000 scan command it tells me there are 0 networks! I know that it should see at least 2 networks (and it did earlier in my testing) and it continues the behavior even after a power fail.

So I began some testing and I issued cc3000 startscan 1 and still no luck on seeing any APs. I then power failed the board and it now can see the 2 networks that it should see. So it would seem that the cc3000 startscan 0 is a bad thing to issue!

I let the unit sit for some time and looked over to see it showing "Callback: Disconnected" and I then sent a cc3000 scan and the board is reporting 0 APs found. I know that my two are available and have decent signal strength because my phone can see them. I also checked with a WiFi scanner tool on my tablet and both APs show good signal strength. Is it possible that I got a semi-faulty board?

[Carl-SolderSplash]

"cc3000 startscan 1" will tell the module to only scan every 10 minutes.

try "cc3000 startscan 10000" this will give you 10 second scans value is in milliseconds

"cc3000 scan 0" disables scanning so will report 0 ap's