My Spark core seemingly abruptly started power cycling during runtime, seemingly otherwise uninterrupted.
Currently it’s set up to read values from two sensors, one on a digital pin and one via i2c — and publishing via Spark.publish() those values to an API and via webhooks to librato and IFTTT — this seemed to be working fine until some point yesterday afternoon.
My first potential culprit was a 2-second delay() call (made mandatory by the DHT22 sensor hardware), which I’ve removed in favor of a hopefully kinder while(now < millis() + 2000);
And additional problem that arose yesterday, seemingly at about the same time, is that I can no longer flash new firmware from the IDE except if I do a deep reset (dfu-utils etc.) and run through particle setup afresh.
Anyone have theories about how to go about solving this? I’m uncertain how to proceed in my debugging tree.
Ha. The push notification for your message arrived just as the update loaded and core LED changed from magenta to flashing yellow. Well off to reverse this!
You may want to trim out bits of code to try to identify the cause of the problem. If you know which bits of code you added before the problem appeared, try removing that.
If you can par the code down to the minimum that still has the problem I can try to find the reason for the restart.
I have done some experiments. Turns out I have a second spark core, which I flashed with the most basic/stripped down version of the code (not that I have snapshots, but essentially what it would have been a few days ago).
I have repro that this causes the core not to be OTA updatable, and that I’m seeing the same resetting recurring.
More data — I have not yet been able to isolate code down to a cause. However, I do have some #overlyHonestMethods to share for continuing to chase down this debug.
I performed a factory firmware reset while the code I’ve been working on was loaded
I flashed the same sensing code
I was able to flash the Blink-LED program (this is amazing! First time since whatever this issue is began that I’ve been able to flash new firmware after programming once without doing a factory reset)
I was able to flash the Blink-LED program again
I then flashed the main sensing project code again
I was unable to flash Blink-LED again but, it’s late… and I feel out of things to try. so I just pressed the program button again and again. The 8th time reported successful programming!
Except it didn’t quite. The core shut off (led out) for several seconds after a blinking-magenta phase. It has come back online but it clearly is not running Blink-LED. In fact it is still publishing data to the API, so it must have gone into program mode, but then kept the existing firmware. I am not confused about this: the Blink LED code is up and positively confirmed as the most recent thing I was flashing.
I am still seeing the core happily reboot at semirandom intervals (it’s not quite periodic, but the timing intervals seem somewhat well constrained in terms of upper and lower bound for probabilistic duration between resets occurring)
The main differences between this and what I had before is I have modified the delay that was part of the main loop from 2000ms to 500ms. I don’t see any changes in the reset timing interval, but it might be a factor in my semi-success at getting the core to flash… something (or at least going into firmware-flash mode).
Worth noting is this is also the core which was my backup hardware. (to ensure that it’s not a HW fault.) Both cores have been updated to CC3000. The two libraries I am relying on are #include SHT1x and Adafruit_DHT.
Thank you so much for reading all this and for all your help here.
Able to repro: Successfully flashed Blink-LED after pressing the Flash button in the IDE only 3 times this time (first 2 requests timed out.) Blink-LED is now running.
The DHT-22 library you are using is known to cause problems and crashes. Can you switch to the PIETTETECH_DHT135 library instead? This will help a lot!
Well, hm. After completely removing the Adafruit DHT library and replacing it with PIETTETECH — still seeing the particle reset itself, and still seeing issues with flashing code more than once without a factory reset.
Also observed a new thing, where normally the breathing cyan will occasionally flicker and I’ll see the device reset and come online again, for sometimes turning off and switching to flashing red for an indeterminate amount of time before coming back online. I suspect right now this is a panic code trigger?
Alternately, breathing cyan just went away and after several seconds (5+) of flashing cyan, the core LED turned off entirely for several seconds (5+) and then reset (cyan, flashing green, breathing cyan again.)
Is there any other possible explanation for what might be happening here?
This is caused by some bug in the code. We don’t know where or what, which is why it’s a good idea to try to prune the code until the problem disappears. It’s a process of elimination.
And I am still seeing it reset itself while otherwise just running (LED blinks out and then LED flashes red) and I cannot reprogram it because the request times out without applying the dfu-util firmware flash. I am a sad star with a sad particle.
[edited to reflect actual code — originally published with an accidental extra right curly brace]
@kennethlimcp yes - thanks. that does work every single time, and is how I have been limping along in getting programming to continue. however doesn’t help me understand/fix the problem or get the thing I need to work going