Core stops publishing, variables aren't visible, but it's still running and online

I have a black core that has been running since November, returning humidity, temperature, and light values both via variables and publish(), and this morning the google script that monitors it started return “fetch failed”, no publishing is occurring, and curl’ing the device returns timeout. Meanwhile, the code is obviously running, because it flashes a status light and goes into and out of deep sleep, connecting every time. Both the web IDE and the dashboard show the core as online (little blue circle).

When I cycle power the core comes up, connects, and starts flashing my status led as expected, after a while it goes into deep sleep and then recovers on time, connects, and repeats as above. If I try to flash the core from the web it times out. I used dfu-util to reflash my code, minus the deep-sleep mode, and it still behaves as described in the first paragraph (except for deep-sleeping): it’s clearly operating, the web IDE and dashboard show it online, but it appears to be incommunicado. I don’t see anything like this in searches, and am not sure how to proceed at this point.

Any ideas?


Could you try a factory reset and see if you can then flash it from the Web IDE? Alternatively, flash the Tinker firmware over USB and see if the Web IDE works again. It might be that your user code is interfering with the flashing process, trying the aforementioned should eliminate that option.
Depending on what method you’re using for subscribing/querying, you might want to check if your accesstoken is still valid. You can generate a new one on the Web IDE which will no longer expire.
Does the Dashboard show your publishes properly? You could also try the Particle CLI with particle subscribe mine.

I know that the access token is good because when I do a curl with a bad token I get a token error, and when I do a curl with the token I’m using, which works with my other cores, I get just the timeout. The dashboard had been showing the publishes properly for this core and continues to show them properly for the others, and this core outputs serial data to a terminal on a local com port, so I know that the data is being acquired properly. After the serial output should come the publishes, but they never appear now. And I always suspect that my code might be screwing things up, but it’s pretty simple and has been running without doing that for quite a while, so I’m a bit mystified that it would suddenly start.

I’ve been putting off doing the factory reset because I expect that will solve the problem at the cost of destroying any opportunity of determining the root cause of this problem, which means that I may be just as perplexed again in the future. I’m starting to feel as though that’s my only option, though,so I may just go ahead and do it.

Can you make a version of your code that we could run on a bare core/photon to test? We can then debug the code and see what’s going on.


When you say “run on a bare core” do you mean that you’d like the code to be able to run with nothing connected to the core? I commented out the call to get the DHT22 values and now have the core by itself on an empty protoboard where it is behaving the same way, though the numbers it is producing are completely bogus. How should I send you the code?


Yep, just a core with nothing connected. If it’s not much code you can paste it here, and some instructions on how to test, what the expected vs. actual behavior is. Thanks :slight_smile:

Well, that didn’t go the way I expected. I thought I’d try to see if I could get any code to load and behave properly in this device, so I put together a trivial program that made a variable, published, and output to the serial port, and loaded it via dfu-util. It ran, the variable appeared, the publish worked, and I was able to reflash it. I threw the other code back in and it flashed ok and started working just like the old days. I have subsequently reflashed it a couple times and it still is working. So I’m at a loss. If you’re still interested in seeing the code I can put it up; it’s about 200 lines. If you’re not, I understand and appreciate the help and suggestions.

If you think I can help you with the problem, then I’ll happily look at the code, although it sounds as if somehow the problem has resolved itself?

Did you performe a cc3000 update at any time? That would improve the stability of the Core regarding OTA updates.

I will be on travel through the weekend and will get back to this after that. I received this core after you guys launched the Photon campaign, so I think it’s got recent cc3300 code in it. How do I tell the version of the cc3300 code?