I am using the spark to monitor a water tank. It communicates to a Raspberry Pi using TCP Client/Server functions. It Spark and Pi talk very well for hours, then the Spark hangs. I get timeout on the Pi and the Spark will not respond to ping. Pushing reset get it happy again. If I use Spark.connected() and it comes up false, can I get the Spark to reboot?
BTW, How do you reboot the core via software?
-
Are you using a black core?
-
The latest CC3000 patch had the ping feature turned off
-
The latest bootloader has the software reboot code but @Dave know better
The top surface of the core is black, so I guess its a black. I think I’ve pinged it in the past, but I ping everything, so who knows. Will the latest patch automatically get included in a cloud compile? I haven’t explicitly updated the CC3000. If ping is off, can it be turned on again? Why was it turned off in the first place?
How would you decide whether to have the Core reboot itself? I really don’t know what’s going on inside it. Is there a place to store logging data that would survive a reset?
Another question: How are timeouts handled on the TCP Server/Client functions. I don’t see a way to set/query them. Could the Core be hanging on a transaction?
The core will handle that portion and attempt to connect to other networks if the existing one dropped.
There’s an ongoing feature done up for users to have full control over cloud connection. Thats should help a lot in checking the status etc and deciding whether to perform a reboot or not.
Right now cloud connection is handled by the core. If you are using TCP in your own code, you will have to handle that 
TI claim to be working on the ping issue (it’s not as simple as it used to be enabled, now it isn’t - there have always been issues with ping behaviour within the CC3000, they are just different now) - it is on the list of fixes planned for the next CC3000 firmware release from TI.
1 Like
Should I start a new discussion about how to do a software reboot and how to detect failed TCP communications?