There are a number of threads relating to the same general issue, which is that the Core becomes unresponsive after flashing your own code, and needs to be factory reset to get it back in action. I wanted to start a new thread to explain the issue, how to avoid it in the short term, and what we’re doing in the long term to fix it.
So here’s the rub:
- If you write code that blocks for a significant period of time (more than a couple of seconds), it may block communications with the Cloud. This means that an over-the-air firmware update can’t be run, because the Core isn’t receiving messages from the Cloud.
- Blocking code includes
delay()and opening a TCP socket using
TCPClient, because the CC3000’s
connect()function blocks for up to 60 seconds when it fails to connect.
- There is a fix in the works, which involves decoupling the Spark firmware and the user application so they don’t block each other. This is top priority for us, but it’s going to take some time. We’ll let you know when the fix is available, and it will be distributed with new firmware that you flash from the web IDE.
- In the meantime, try to avoid long delays if you can, or break them up so that your
loop()doesn’t take more than a couple of seconds to run. In the case of TCP, if your socket opens successfully, it should work fine.
- If you do encounter this issue, a factory reset should always solve the problem, or you can do your development locally and program the Core over USB.
Questions or comments? Reply to this thread!