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?

I'm trying to upgrade my CC3000 firmware, but I'm running into the issue described in the title.

I'm able to start the process through the serial monitor, and it displays the RX/TX buffers and RAM on the CC3000, but crashes during initialization.

What's throwing me off is that when I run buildtest or one of my own sketches, I can get past the initialization process without any issues.

Could this have something to do with the "if (!cc3000.begin(2))" command on the driverpatch sketches? buildtest and the other sketches that work use cc3000.begin()

In all cases I'm using an Atmega1284p with the ManiacBug bootloader.

Any help would be appreciated!

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

I modified WebClient.ino to fire a request in loop() rather than setup().

It seems like if we do delay(t>30) the board will crash.

Serial.println(1), Serial.println(2), ... were inserted for debugging purposes.

If INTERVAL is set to 45:

Hello, CC3000!

Free RAM: 6876

Initializing...

Attempting to connect to Cisco21623
Connected!
Request DHCP

IP Addr: 192.168.1.141
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DHCPsrv: 192.168.1.1
DNSserv: 75.75.75.75
207.58.139.247INTERVAL:45
1
2
SENT AT:26114
3
4
<console hangs>

However, if INTERVAL is set to 30:

Hello, CC3000!

Free RAM: 6876

Initializing...

Attempting to connect to Cisco21623
Connected!
Request DHCP

IP Addr: 192.168.1.141
Netmask: 255.255.255.0
Gateway: 192.168.1.1
DHCPsrv: 192.168.1.1
DNSserv: 75.75.75.75
207.58.139.247INTERVAL:30
1
2
SENT AT:27435
3
4
5
1
2
SENT AT:57830
3
4
5
1
2
SENT AT:88304
3
4
1
2
SENT AT:118709
3
4
... (goes on indefinitely)

My code can be found here: https://gist.github.com/vicngtor/5616b24751763ff6bb04

Building on the recent addition of the TCPServer code, I added some basic HTTP server logic. It doesn't do much more than parse HTTP method and path, and provide these to an HTTP handler callback function.

Open the WebClient example from the Adafruit_CC3000_Library, set it up for your network credentials, and use:

define WEBSITE "45.55.159.249"

define WEBPAGE "/test.hex"

I expect it will start downloading and printing out the file, but will eventually halt and timeout before the end of the file is reached. Loading the same thing in your web browser works without a hitch: http://45.55.159.249/test.hex.

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 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

This small change adds support for the ATmega1284P processor using the popular 'Mighty 1284P' pinout (as documented at http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/ and https://github.com/maniacbug/mighty-1284p/). Unfortunately there is no official Arduino pinout for the ATmega1284P processor, however the 'Mighty 1284P' bootloader and pinout is the most well documented, and follows the conventions of official Arduinos.

This change was tested using an ATmega1284P setup as a breadboard Arduino running the mighty 1284p bootloader. The buildtest, chat server, and web client examples were run to verify functionality.

This pin to interrupt mapping should also work for other processors like the ATmega1284, ATmega644A/PA, etc. but has not been tested with them so they weren't added.

This commit does the following:

• Removes the transmit buffer from being a member of each client instance. The transmit buffer is only used to buffer strings from flash memory to send out on sockets, therefore it's not necessary to have a separate buffer with each client. The transmist buffer is now a local variable of the fastrprint function.
• Adds a test directory with a small suite of tests for the fastrprint function. A README.md explains the usage of the tests, and a small python script is provided for capturing output of tests.
• Fixes a few bugs with fastrprint and fastrprintln calling send (and sending garbage data on the socket) when they receive a null string. Simple string length checks now catch these conditions and respond appropriately.
• Puts an end of line constant used by fastrprintln into flash memory instead of RAM.

This commit was tested by running the included Client_fastrprint test suite before and after the changes, capturing the output of these tests, and comparing the before/after output with diff to ensure there was no change in functionality. Execution time of the tests before and after was mostly unchanged, 134 vs. 135 milliseconds. Memory usage with multiple clients decreased as expected by moving the tx buffer out of each class instance.

I have a project that runs 24x7 and uploads stats every 30 minutes. a couple times a week I find the system hung with the display showing its stuck in the read loop.

I have implemented a internal watchdog and the hang is severe enough to even lock that up so no reset is occurring. Has anyone else encountered similar behavior?

external watchdog comes next I guess.

ref: https://github.com/dzzie/humidor.net/blob/master/Arduino/humidor/humidor.ino#L424

simplified:

  startTime = millis(); //unsigned long
 #define IDLE_TIMEOUT_MS 7000 

  while (www.connected()) {

    if( (millis() - startTime) > IDLE_TIMEOUT_MS ) break;

    while (www.available()) {

        if( (millis() - startTime) > IDLE_TIMEOUT_MS ) break;

        char c = www.read();
        ...

    }
  }

  wdt_reset();