I have a cc3000/Uno collecting data and posting it to a database on my LAN. After running for some time, it stops and locks up in the readResponse routine. A reset fixes the problem each time but I would like to have it run continuously unattended. The cc3000 firmware is v1.24. Here's the routine where it is when it stops while printing chars to the screen while in debug mode. I have similar Unos running on the same LAN but using ethernet shields and they have been working for 3 months without a hitch.
/**************************************************************************/
/*
Read and display response from server
Return true if client was available
*/
/**************************************************************************/
boolean readResponse(Adafruit_CC3000_Client cl)
{
boolean stat = false;
/* Read data until either the connection is closed, or the idle timeout is reached. */
unsigned long lastRead = millis();
while (cl.connected() && (millis() - lastRead < IDLE_TIMEOUT_MS))
{
while (cl.available())
{
char c = cl.read();
DEBUG_PRINT(c);
lastRead = millis();
stat = true;
}
}
return stat;
}
Update: It just locked up at the following location:
/**************************************************************************/
/*
Restart CC3000 using reboot then (re)connect
*/
/**************************************************************************/
void reConnectIfNecessaryCC3000()
{
if(! cc3000.checkConnected() )
{
cc3000.reboot();
delay(3000);
// Now connect to the AP again
DEBUG_PRINT(F("\nAttempting to connect to ")); DEBUG_PRINTLN(WLAN_SSID);
if (!cc3000.connectToAP(WLAN_SSID, WLAN_PASS, WLAN_SECURITY))
{
DEBUG_PRINTLN(F("Failed!"));
while(1);
}
DEBUG_PRINTLN(F("Connected!"));
delay(1000);
/* Display the IP address DNS, Gateway, etc. */
displayConnectionDetails();
}
}
It sounds like you're running into a cache overflow in the CC3000 firmware, and yes, that's a TI bug.
The Arduino does have a watchdog timer, but you could probably use clock-based interrupts too. Set a timeout interval just before calling a function that could hang, then clear it immediately after the function call. If the call succeeds, the timeout gets shut down before doing anything. If the call hangs, the timeout will trigger an interrupt handler that can do damage control.
You'd have to check with TI on that. There have been a couple of upgrades since we first started using the CC3000, but knowing a bug exists is different from knowing whether you can fix it in code or need to spin hardware changes into the chip.