Hi, I got the buildtest sketch working on my Arduino Due.

When I have done some more testing, are you interested in getting a pull request for the changes? I'm trying to make sure the changes will be compatible with the other boards that are currently working.

I noticed this while running all the examples to test a pull request. It looks like the version of avr-gcc that Debian/Ubuntu installs with the arduino package is version 4.7.2. When I load the ntpTest example and try to compile it fails with errors like this for all the string constants and string constant arrays:

ntpTest.ino:78:22: error: variable ‘janStr’ must be const in order to be put into read-only section by means of ‘__attribute__((progmem))’

It looks like the normal Arduino version from their website by default installs and uses the earlier avr-gcc version 4.3.2 which does not have any issues compiling this example.

This probably isn't a big priority to fix right now, but is a good thing to be aware of when/if Arduino moves to a later version of avr-gcc. The fix appears to be to just make all the string constants const, such as:

const prog_char janStr[] PROGMEM = "January";

And also make the string constant arrays const with:

PROGMEM const char* const monthStrs[] = { janStr, febStr, marStr, aprStr, mayStr, junStr, julStr, augStr, sepStr, octStr, novStr, decStr};

If you want I can submit a pull request with this fix.

I've been debugging a few recent intermittent lockup issues and found the recent change to add support for the Due (this one f1172f2 ) accidentally dropped the default SPI clock speed from CPU clock speed div 2, to clock speed div 128. This value is likely right on the edge of being too slow to communicate with the CC3000 reliably and explains the intermittent nature of the issue. The fix should be straight forward, for the non-Due platforms set the default SPI clock speed back to div 2. Opening this as an issue first and then sending a pull request with the fix separately.

The CC3000 stops responding on the wifi after a few working exchanges using the ChatServer example on the Teensy3.1 with the breakout board. Right before all SPI action stops, there is a different looking IRQn and SPI read exchange. Different enough it is possible to trigger on this, and some resulting plots are posted here:
http://forums.adafruit.com/viewtopic.php?f=31&t=50176

I'm using the various examples like the WebClient and InternetTime on various networks and the one thing that keeps tripping me up is when the network password is longer than 16 bytes/chars. I have several secure networks that have long passwords that cannot be changed without serious implications.. i.e., hundreds of devices/computers need new passwords entered. Super headache. Some I don't even have the power to change.

The error I get is Key length must be < 16 when using the cc3000.connectToAP(WLAN_SSID, WLAN_PASS, WLAN_SECURITY); function.

That said I found this place in the code where the MAXLENGTHKEY is defined and it says the following:
#define MAXLENGTHKEY (16) /* Hard coded to 16 in the API! :( */

Link here:
https://github.com/adafruit/Adafruit_CC3000_Library/blob/master/Adafruit_CC3000.cpp#L67

So I decided to see how sad that sad face really was CHANGE the max from 16 to 32, but to my surprise it worked! My 24-byte WPA network password was a success and my connection and WebClient HTTP GET request were up and running.

So I'd submit a pull request to change this, but there seems to be something to it with that frownie face and all... thoughts?

I got a CC3000 in the mail the other day, and I finally got around to wiring it up today. I couldn't find any clear instructions on the arduino pins used (it is defined in one of the files in the library though). I thought I'd save others the trouble by making a little diagram. It's very low-fi (not fritzing or anything) but it may help someone:

Old Incorrect Diagram Archived for clarity: http://imgur.com/CqdcDEM

Corrected diagram thanks to DubbyTT

Howdy,
The CC3000 shield has been working fine for me on an Arduino Uno.
I've just switch over to an Arduino Mega 2560 and programs that used the CC3000 could not be upload anymore. Other programs works fine on the Mega if it doesn't use the CC3000 library.
Any hint on where I should look to fix this.
Thanks,
Tuan Bui

Hi All,

I am writing a MDNS responder for ATMEGA 2560 with CC3000.
I am opening a UDP socket to mDNS address/port and am listening/responding to mDNS queries.

When the code goes in select API to check for any recv packets, the code will get stuck and loop inifintely in hci_event_handler() or in SpiWrite method.
In some networks(multiple machines generating mDNS traffic) it happens very frequently i.e. I am able to reproduce within 4-5 mins.

I am able to reproduce similar issue using the CC3000_MDNS sample (although, reproduction frequency increases ONLY when I modify the buffer size to ~100 bytes in Line 197 in CC3000_MDNS.cpp).

My CC3000 has currently v1.24 Service Pack.

On TI CC3000 forum site, I am able to see many folks encountering hang issues with CC3000 but am not sure if their issue is similar to mine.

I've been reading around to find various solutions to my problem.

Problem: CC300 wifi + MQTT client (PubSubClient).

The only solution I've found so far is a hack:

• http://stackoverflow.com/questions/22292692/mqtt-for-arduino-cc-3000
• https://github.com/nathanchantrell/pubsubclient

There's a thread here that talks about trying to make this library compatible with the Ethernet Client class: https://twitter.com/nathanchantrell/status/437738355498180608

Is anybody working on this or are interested in working on this?

cheers
James

When I send a str of 127 characters (+1 for the terminator) like this:

char charArr[255];
String name = "255,255,255, ... ,255";  // (127 characters in all)
name.toCharArray(charArr, name.length()+1);
client.fastrprint(charArr);

The last line hangs. With shorter strings, it doesn't hang. I don't know the exact boundary.

However, I noticed in fastrprint(const __FlashStringHelper *ifsh) that there's a check:
if (idx >= TXBUFFERSIZE)

fastrprint(const char *str) doesn't do any of this kind of checking, so I basically copy & pasted the code (with a few modifications), not totally knowing what I'm doing, but this code worked (it no longer hung after passing it a long str):

size_t Adafruit_CC3000_Client::fastrprint(const char *str)
{
    Serial.println("CC3000_Client::fastrprint(*str)");
    char _tx_buf[TXBUFFERSIZE];
    uint8_t idx = 0;

    //const char PROGMEM *p = (const char PROGMEM *)ifsh;
    size_t n = 0;
    uint8_t i = 0;
    while (1) {
        //unsigned char c = pgm_read_byte(p++);
        //unsigned char c = str[i++];
        char c = str[i++];
        Serial.print(c);
        if (c == 0) break;
        _tx_buf[idx] = c;
        idx++;
        if (idx >= TXBUFFERSIZE) {
            // lets send it!
            Serial.println("Sending cuz reached TXBUFFERSIZE");
            n += send(_socket, _tx_buf, TXBUFFERSIZE, 0);
            idx = 0;
        }
    }
    if (idx > 0) {
        // Send any remaining data in the transmit buffer.
        Serial.println("Sending remaining data");
        n += send(_socket, _tx_buf, idx, 0);
    }

    return n;
}

It looks like fastrprintln(const char *str) also needs these same changes (TXBUFFER checks) added to it.

Sorry I can't provide more detail, but I'm guessing this enough information for you who know this code well, and can see why it would hang with long strings, and you'll know the right way to fix it.

Thanks for looking into this & fixing it for us.

Code in Adafruit_CC3000 and Adafruit_CC3000_Server rely on non tiny functions

I'd like to remove the transmit and receive buffers from the client class (the _tx_buf and _rx_buf private members), but want to run the change by folks to see if there are good reasons to keep these buffers as members of the client class.

My rationale for removing them is that there are subtle issues with these buffers, and they prevent the class from being copyable (more on that further below). Here are a couple buggy situations that can happen today:

• User copies an instance of a client class and calls the read() function on both instances. Each instance will read from the same socket, but neither will have a buffer in exactly the same state as they each have their own copy of the buffer and buffer indices. Calls to read() between both instances will return inconsistent results, like duplicate results (read from one copy, then the other) or missing data (first read from one copy so it pulls a buffer load of data from the socket, then read from the other copy which has no data and pulls an entirely new buffer load of data from the same socket).
• Mixing calls to the two read functions will produce inconsistent results. For example if you call read() with no parameters and get one byte back, then call read() with a buffer and size of data to retrieve you won't get back the data that was pulled into the rx buffer by the earlier read call (because the overload of read that takes a buffer just calls recv on the socket directly).

For the issue with copying client classes you could make an argument that users shouldn't copy the class, and even make an explicit copy constructor that's private to prevent this, but I think you'll harm the usability of the library. In particular if we want to use the Arduino Ethernet library as a model for this one (or at least an ideal for compatibility), we need to allow the client class to be copyable without any bad side effects. See this chat server code for an example of how the Ethernet library's server code uses a pattern of the available() function returning a copy of a client class which is available for reading data: http://arduino.cc/en/Tutorial/ChatServer With the CC3000 client class it will be very problematic to implement the same pattern because of the issue with copying clients above. An easy workaround would be to have users deal with pointers & references to clients instead of copying them, but that won't be compatible with code written against the Ethernet library and could be dangerous for inexperienced users.

As far as removing these buffers, here's what I propose:

• For the tx buffer it looks like it's only used in the fastrprint function which takes a pointer to a flash memory string and writes the data to the socket. This buffer is really just used within the context of that function, so it should be a simple and low risk change to make the buffer a static variable. This would also save a little bit of memory as each client doesn't need their own tx buffer instance.
• For the rx buffer I think we should remove it completely. The read() function that takes a buffer and size will not be impacted since it's just calling recv without any buffering today. The single character read() function will be updated to attempt to read just one character with recv (similar to how the Ethernet library client works). The available() function will also be updated to only do the select() call on the socket with a short 5 millisecond timeout.

If there's a good argument to keep the rx buffer functionality, I think we should at least push the buffer state up into the global library state, similar to how the closed_sockets array that holds socket connection state works. This would fix the issues with copying clients while still giving the ability to buffer reads.

Sorry for the wall of text issue. :) I wanted to understand any reasons to keep these buffers before I put together a pull request to remove them (and enable a server interface similar to the Ethernet library).

Are there any plans for providing a simple REST client (GET, POST, PUT, DELETE) example/lib?
-- Thomas

It looks like (from your Adafruit CC3000 Wifi Shield & Breakout Board product pages) that the CC3000 supports: "TCP and UDP in both client and server mode". And your library currently supports: "UDP/TCP client & TCP server connections".

Is the UDP Server side of things a work in progress? Or is it something too complicated to implement?

I think I need a UDP server to be setup for what I'm trying to accomplish (and I'd think many other users would like to do as well) - I'd like to rapidly send "Color" packets to control your NeoPixel strips. I need at a MINIMUM 20 packets (colors) / second, though 30 or more would be best (no flickering). Using the TCP server method I got about 2 frames / sec, and with some hacking, got it up to about 5 frames / sec. (I may be doing something wrong, but I've even analyzed the TCP stream with Wireshark, and it appears the CC3000 side of things has about a 20ms delay before sending most or all of it's packets - which adds up to a lot of time pretty fast).

I have Javascript which AJAX calls a PHP script on a mouse move/drag event on a color swatch. The called PHP script gets the color and sends it out as a UDP packet to where ever you tell it.

I understand the UDP Server is not currently supported in the library, but if you could point me in the right direction (if possible) I would greatly appreciate it! Any solution to receiving ~20-30 packets / second of color (3 data bytes) packets would be great!

Transferring data using the library is quite slow. It seems to transfer relatively small packets over the network. Can we use this issue to (1) corroborate the performance is a problem and (2) try and identify the root cause? Where is the bottleneck? Watching a large file download in WireShark shows data being transferred in 54 byte length packets... what's driving that?

Hi Adafruit team!

I've hooked up an Adafruit CC300 board to a femtoduinoUSB board ...which uses an ATMEGA328p-mu

However, maybe something with my SPI signals is goofed... I get all the output on the Serial prompt up to when it says "Initializing CC300..."

...and then, nothing else.

Do I need to check for something obvious, besides connections? I've hooked it up according to the info on the adafruit page. Kinda stuck.

Can anyone help me trouble shoot this? Perhaps I need to add some debugging lines in the .cpp files?

Dear,
this is my beginning code for transfer file by FTP protocol to server. My code hand out and stop at client.println(F(PASS ****)); see below.

anybody tryed an FTP transfer with the CC3000 library ? Or a valid code. After many days, i'm still searching for a code allready done, but I don't find anything on the web.
I'm trying to make my own but not really successfull... 👎

Thanks at all.
EraSiuS.

// ARDUINO + CC3000 WIFI Shield + FTP Protocol transfer
// CODE of doFTP function
byte doFTP(){
uint32_t IPci = cc3000.IP2U32(0,0,0,0);
client = cc3000.connectTCP(IPci, 21);
if (client.connected()) {
if(!eRcv());
delay(500);
Serial.println("USER READY FOR SEND");
client.println(F("USER ****"));
Serial.println("USER SENT");
if(!eRcv()) return 0;
delay(100);
Serial.println("PASS READY FOR SEND");
client.println(F("PASS ***"));
Serial.println("PASS SENT");
if(!eRcv()) return 0;
delay(100);
}
}

// DESCRIPTION OF SERIAL RETURN
// Connect to 0.0.0.0:21
if(!eRcv()); // DISPLAY on Serial : 220 ProFTPD 1.3.3g Server (ProFTPD) [0.0.0.0] // WORK
delay(500);
Serial.println("USER READY FOR SEND"); // DISPLAYED on Serial
client.println(F("USER **")); // USER for ftp
Serial.println("USER SENT"); // DISPLAYED on Serial
if(!eRcv()) return 0; // DISPLAY on Serial : 331 Password required for ***
delay(100);
Serial.println("PASS READY FOR SEND"); // DISPLAYED on Serial
client.println(F("PASS ***")); // password for FTP account
Serial.println("PASS SENT"); // NOT DISPLAY on Serial, "client.println(F("PASS ***"));" FAILED
if(!eRcv()) return 0; // NOT DISPLAY : no response

I'm wondering if you could explain (here or in a forum, if this is not the right place) the difference between these classes:

Adafruit_CC3000
Adafruit_CC3000_Client
Adafruit_CC3000_Server
Adafruit_CC3000_ClientRef

I "think" I "almost" get it from looking at the example code, but if you could explain WHEN and HOW to use each of the above classes, that would be helpful.

Thanks!

I'm getting this error trying to compie the "Echo Server" example:

$ ino build
Robot_Control/glcdfont.c
/usr/share/arduino/libraries/Robot_Control/glcdfont.c:9:23: error: variable 'font' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static unsigned char  font[] PROGMEM = {
                       ^
make: *** [.build/pro328/Robot_Control/glcdfont.o] Error 1
Make failed with code 2

The buildtest example tries a DNS lookup exactly once:

Serial.print(F("www.adafruit.com -> "));
  if (! cc3000.getHostByName("www.adafruit.com", &ip)) {...} else {...}

On our institutional network, the first call returns ip 0.0.0.0 which buildtest then happily but unsuccesfully tries to use for a ping.

The WebClient example has a better lookup routine that repeats the attempt if 0.0.0.0 is returned:

ip = 0;
  // Try looking up the website's IP address
  Serial.print(WEBSITE); Serial.print(F(" -> "));
  while (ip == 0) {
    if (! cc3000.getHostByName(WEBSITE, &ip)) {
      Serial.println(F("Couldn't resolve!"));
    }
    delay(500);
  }

This should also be used in buildtest.

Is it possible to derive Adafruit_CC3000_Client from Stream instead of Print?

The various find and parse functions in Stream (http://arduino.cc/en/Reference/Stream) would be useful for parsing incoming data (e.g. HTML or RSS feeds).

I'm submitting this issue per this forum thread: http://forums.adafruit.com/viewtopic.php?f=22&t=47371

When fastrprintln() is called, the code hangs and doesn't finish. I'm sorry I can't offer more help -- I'm just a hobbyist :(

hi there

I've had a pretty annoying issue using SublimeText and STino.
I've noticed that I had an error raised during compilation, and it was due to how STino preprocesses files to compile sketches.

basically it was pre-compiling the WiFI/utility/socket.cpp before it got to compile Adafruit_CC3000/utility/socket.cpp

I only realised because the error was related to
#define SOCK_NOT_AVAIL 255
which appears in the WiFI socket code.

maybe it could be a good idea to uniquely name this class to af_socket
not sure if I make sense :)

thank you

Running CC3300 on UNO or Teensy 3 the first call to getHostbyName() returns the correct IP. Subsequent calls with different host names return the same IP as the initial first call. In a loop, eventuall one of those calls returns a correct IP but then again, all subsequent (different hosts) calls return that IP. Reflashing the CC3300 firmware (1.24) does nothing. This condition was initially observed running the SendTweet sample sketch. The first call is in getTime() and subsequent calls should be to api.twitter.com but instead IP returned is of time server.

WebClient example sketch hangs when reading weather forecast in XML format from w1.weather.gov. Sample output:

Hello, CC3000!

Free RAM: 1189

Initializing...
Started AP/SSID scan




Connecting to SKY0868E...Waiting to connect...Connected!
Request DHCP

IP Addr: 192.168.0.9
Netmask: 255.255.255.0
Gateway: 192.168.0.1
DHCPsrv: 192.168.0.1
DNSserv: 192.168.0.1
w1.weather.gov -> 176.255.202.75

Connect to 176.255.202.75:80
-------------------------------------
HTTP/1.0 200 OK
Server: Apache/2.2.15 (Red Hat)
Last-Modified: Sun, 03 Nov 2013 11:02:14 GMT
Accept-Ranges: bytes
Content-Length: 2270
Content-Type: application/xml
Date: Sun, 03 Nov 2013 11:35:29 GMT
Connection: close

<?xml version="1.0" encoding="ISO-8859-1"?> 
<?xml-stylesheet href="latest_ob.xsl" type="text/xsl"?>
<current_observation version="1.0"
     xmlns:xsd="htt

To replicate: Change target website in unmodified WebClient example to:

// What page to grab!
//#define WEBSITE      "www.adafruit.com"
//#define WEBPAGE      "/testwifi/index.html"

#define WEBSITE       "w1.weather.gov"
#define WEBPAGE       "/xml/current_obs/KNYC.xml"

With some fuzzy math trying to account for a similarish example file, here are other library sizes for comparison

Arduino Wifi
~8,296 129 bytes global variables

Arduino ethernet
~13,512 272 bytes global variables

Adafruit cc3000
~17,634 607 bytes global variables

Adafruit cc3000 with CC3000_TINY_DRIVER
~16134 543 bytes global variables
This is pretty fuzzy too because I had to comment out necessary code in order to compile the tiny driver, see #75

Thus I conclude the library is currently pretty big. Both in program storage and global variables. My personal concern is currently more around program storage as thats where Im having trouble.

I poked around the source and with debug off I dont see any low hanging fruit like strings in flash or egregious standard library use..

Any thoughts on where to start?

Should it be somewhere within the library?

Guys,

I am getting stuck at initialization for the CC3000. Need to confirm, is there a specific way to solder the headers?

It feels like it is related to:

• When the requesting side stops the connection and opens one (or many) new ones to fast.
• Maybe to many packages send in the same time?
• Maybe some buffers that are overrun in the Adafruit Library?

  Are more people having this issue?

Could it be possible to have a function that tells if all packages are received, send successfully or unable to send due a closed connection? This function can help me to wait until the message is send instead of just blindly delay by a magical amount.
Is something like that supported by the cc3000?

Please refer to this forum thread:
http://forums.adafruit.com/viewtopic.php?f=31&t=46824&p=236023#p236023

After about a half-hour, EchoServer hangs. It no longer responds to characters typed into telnet, will not accept new telnet connections, and the cc3000 stops responding to Pings.

Reproduced the problem several times. Most recently, it stopped echoing after about 10 minutes, but would still accept new connections and respond to ping. However, it does not echo new connections.

Using Adafruit Shield, firmware 1.19, Arduino Uno R3

The output from "buildtest" sketch:

Hello, CC3000!

RX Buffer : 131 bytes
TX Buffer : 131 bytes
Free RAM: 1247

Initialising the CC3000 ...
CC3000: init_spi
CC3000: Finished init_spi
init
start
CC3000: SpiOpen CC3000: WlanInterruptEnable.
CC3000: Finished SpiOpen
CC3000: ReadWlanInterruptPin - 001
CC3000: WriteWlanPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 001
CC3000: ReadWlanInterruptPin - 0

Hi. You are making an excellent work. But i'm starting a new proyect and i checked that this moule doesn't support work as a server, well the CCS3000 supports that but the code that you are making not. My questiong is. Do you have planned develop that functionality?

Thx.

Does the Adafruit_CC3000_Client support connecting via HTTPS, port 443?

It strikes me that interrupts could be missed in the current implementation resulting in infinite loops waiting for expected IRQ events to occur, but were missed because they took place during the twilight period between when the IRQ handler was detached and then re-attached...

The use of cc3k_int_poll() sprinkled throughout the code is, so far as I can tell, an attempt to cope with that reality, but I think it's flawed / still has the (non-negligible) potential to miss events.

Perhaps a better alternative paradigm is a queuing mechanism. A flag could be set/cleared in SpiPauseSpi/SpiResumeSpi to inform the the interrupt handler that it should queue up processing if an IRQ interrupt occurs, rather than handling it immediately. You would then need a function that the end application would need to call from the main loop() periodically to de-queue deferred IRQ events.

Does that pattern seem worth pursuing as a solution?

Hey,

Thank you for sharing the library.
I really need this library currently.
I tried to run my cc3000 evaluation mode with my arduino,
However, it fails to run until the firmware command.
So it refuses to continue because my firmware is not the latest one.
It is possible if I keep running my cc3000 module without updating the firmware?

I tried to update it with MSP430G2553, but it fails in compiling.
So can you suggest me how to improve my firmware?
Or perhaps you know if maybe I could keep my firmware with same version but still running the CC3000 module?

Thank you in advance!

Stella

In fastrprintln() functions, and other locations, a newline is specified as \n\r in the code, but I believe it should be \r\n, right?

The area I'm running into problems with \n\r is when I send a HTTP header. My safari browser doesn't parse it properly, unless I modify your library to use \r\n instead of \n\r for the line feed.

It appears from this site (http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html), in Section 19.3, that:

"The line terminator for message-header fields is the sequence CRLF."

Thanks for looking into this.

Sometime after Christmas, my CC3000 seemed to stop sending Tweets.

I've only just returned to this problem to find the issue still stands. Twitter have turned off HTTP and moved to HTTPS only for API calls.

I'm guessing that on Arduinos at least we are gong to be stuck to get this functionality back?

Hi guys! Excellent work on the Adafruit CC3000 lib! I noticed there were some caveats, such as incomplete implementation of HTTP stuff, and a need to use a certain version of the Twitter API to get an example running. Could you guys add some "@todo" doc blocks so we know where we can contribute?

Looking forward to contributing!

• Alex Albino, Femtoduino.com

Does this library make any assumptions about the micro-controller speed?
Has this library been tested on 12Mhz and 20Mhz? I have 12 and 20 Mhz arduino and it just doesn't work, it gets stuck on Initialising the CC3000 ... I've got two modules and none of them works, and yes, my wiring is correct.

I'm no expert on creating libraries, but I just spent a good deal of time finding out that the default assignment of the hardware serial port for CC3000 debug info was breaking my setup which used the port for controlling a device (that requires hardware interrupts, and therefore can't use a softserial interface).

My opinion is that instead of doing this:

#if defined(UDR0) || defined(UDR1) || defined(CORE_TEENSY) || ( defined (arm) && defined (SAM3X8E) )
CC3KPrinter = &Serial;
#else
CC3KPrinter = 0;
// no default serial port found
#endif

It would be better form to leave CC3KPrinter null and have an accessor function that would assign it to a serial port based on the users preference. An example could demonstrate that.

Of course I could be missing something, but I didn't see any other libraries doing this.

When starting connectToAP and no AP is available it keeps generating "Timed out!" message and never get's out...

There are a few issues with begin() and stop() using the _intialized variable which mean these functions really can't be called multiple times. Begin will check if initialized and skip all further logic, however this is problematic because it will skip things like calling wlan_start() to turn the CC3000 on if it was off. The firmware update sketch ran into this issue and a workaround was to just call wlan_start() manually. Related to this, stop() doesn't set intialized to false so again begin() won't turn the CC3000 back on (user here ran into the problem).

Opening this as a bug for now to come back to and investigate what _initialized is protecting from running multiple times and how to allow a scenario of begin(), stop(), begin() to work as expected by turning on, off, and then on again the CC3000.

uint8_t Adafruit_CC3000_Client::read(void)
{
... ...
... ...
bufsiz = recv(_socket, _rx_buf, sizeof(_rx_buf), 0);
if (bufsiz == -57) {
close();
return 0;
}
... ...
... ...
}

What's mean about the -57 return by the socket method recv()? I never found any information about this in the documents of TI.

Hey gang,

From the TI CC3000 Host Programming Guide

Because there is no queuing mechanism within the CC3000 host drive, the hci_unsolicited_event_handler function must be called by the user periodically each 500 ms. The function determines if unsolicited event handling is required and, if so, triggers the appropriate callback function. The periodic call to the function can be executed either in the dedicated context of the timer interrupt, for example, or within the main loop of the user application, as occurs in the Basic WiFi Applications.

Do people feel that this should be something the library should be responsible for? Or should it be something users should be required to implement (somehow) in each individual sketch? It doesn't seem to me that is even a possibility in the current code base - trying to call hci_unsolicited_event_handler() at the sketch level results in a compile-time error (undeclared function).

re this forum thread:
http://forums.adafruit.com/viewtopic.php?f=22&t=46901

Need a timeout on connectTCP. Otherwise user code can hang forever when there is a connection issue

Anyone know why there isn't a stop() and flush() method in the Adafruit_CC3000_Client class, akin to the analogous EthernetClient class? My current workaround of "delay(1);" before calling stop() lacks a certain elegance / reliability I find. Anyway, if someone could shed some light on the topic, I would be most appreciative.

FWIW I started by posting a question to the Adafruit forum and got directed to post the question here as an issue.

http://forums.adafruit.com/viewtopic.php?f=22&t=46921

Has anyone given any thought to what it would take to support the arduino due?

I looked through the code for possible problems. I saw a few small places that were marked todo for due/teensy support... Seemed like they were spi related macros?

Is anyone aware of any other trouble spots? I have a due on order... I was thinking I might get one of these shields and see if I can get it working.

I've been playing with the CC3000 Arduino shield for a few days now and am noticing some issues with lockups after the sketch had been running for 30mins or so.

I've now narrowed a bug down to the entire sketch locking up, meaning the loop() method stops being ran. Below is my example sketch which is the EchoServer.ino from the examples with a firmware check and toggling of a LED in the event loop.

Once the device is powered up and is leased an ip address the LED starts blinking about every 5ms. Then i power off the access point the device is connected to. The LED stops blinking.

First I thought this could be an issue with one of the CC3000 server methods blocking after a disconnect but I removed all calls to it in the loop() method.

Any ideas?

Uno Rev 3
Firmware V. : 1.24

Example Sketch
https://gist.github.com/AdamMagaluk/8289685

In the web client example, I just changed the #defines of website and webpage to my own website where I created a temp index.html, its live at black-electronics.com/tmp/index.html ,I can view in my browser, I cant figure out, why is this happening?, do I have to make any changes in my server settings?

define WEBSITE "www.black-electronics.com"

define WEBPAGE "/tmp/index.html"

here is the log:

Connecting to HemalChevliOffice...Waiting to connect...Connected!
Request DHCP

IP Addr: 192.168.1.4
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DHCPsrv: 192.168.1.1
DNSserv: 192.168.1.1
www.black-electronics.com -> 50.87.144.195

Connect to 50.87.144.195:80

HTTP/1.1 408 Request Time-out
Date: Thu, 29 Aug 2013 12:19:07 GMT
Server: Apache
Content-Length: 274
Connection: close
Content-Type: text/html; charset=iso-8859-1

< !DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
< html>
< title>408 Request Time-out</title>
< /head>
< h1>Request Time-out
< p>Server timeout waiting for the HTTP request from the client.

< /body >< /html >

Disconnecting