I was just flashing the core, but then the RGB LED went off and all that remains is the tiny blue user LED. Now, whenever I plug it in all that happens is the tiny blue LED is on… HELP !
had the same issue myself, please try this: https://community.spark.io/t/bricked-main-led-blank-corner-led-solid-blue-solved/2794/7?u=brungle
1 Like
thx, that solved it 
phew!
1 Like
I got the same problem today but thanks to the link Brungle write i got it to work.
1 Like
@binoyxj Is the OTA update halting in between? There is usually a time out period, after which the Core should reset itself on failure. If not, sometimes a simple reset does the trick.
All the Spark servers ans services are up and running: http://status.spark.io/
Hi @binoyxj,
I suspect the “Dim D7 after flashing” is a result of errors when copying firmware across to the external flash chip and back. Normally this is somewhat rare, but we’re working on a fix for this in the meantime.
Thanks,
David
@mohit Yup! That happened twice and finally I had to wait for it to time out. Everything back to normal now.
1 Like
Had this 2 times already while programming over the 
cloud. Something wrong? 
The firmware I’m currently working on started making the Spark Core go dark on every update after I pulled the latest changes a couple days ago. Either A) It would seem to be fine, but if I disconnect power and reconnect power it would be dark, or B) It would be immediately dark. I am building locally, using dfu-util for sending new firmware after it goes dark (not a full reset, just flashing yellow).
I’ve been working on eliminating possibilities…at first it seems like an issue with code running in class constructors, but now I think it might be related to the thermal printer class I have. Note that it was working just fine for a while leading up to this.
I had been trying to track down an issue leading up to this where my firmware would work perfectly for exactly 1 minute, then stop whatever it was doing (even mid-print). This new problem disrupted my investigation so I’m not sure!
Please do let us know if we can help track this down, I really want to quash this bug.
Thanks!
David
This is a weird hunt. I started with a fresh firmware checkout, put in all my libraries, but no main loop code. Binary at 85kb. I got to the point where if I remove a specific, very small class from the build it wouldn’t go dark (a class that isn’t even used!), and if I added it in it would go dark. It wasn’t really changing the binary size though. Then with the class fully removed I added all my main loop code and it goes dark again. Since it doesn’t appear to be a size issue (I think), I’m not sure what is happening. I’m still trying to whittle away code, looking for commonalities…
Another bug I’ve been having, which I had to stop tracking down because of this one (aaaah!), is that exactly one minute after startup, everything stops. No more input, no more printing, etc. I searched the code and found a 1 minute timeout in spark_utilities.h: #define TIMING_API_BLOCKING_TIMEOUT 60000 //60sec
Until I can get my firmware running at all again, I can’t test it (well, I could just checkout an old version of the code I suppose). In any case, if this timeout is triggered, would all execution cease?
Hmm, are you building against latest master, or what branch are you using?
I’m building against the latest master.
Update: I’ve been initializing a few major components of my firmware as such:
cdam::Printer _printer;
cdam::StoryLoad _storyLoad(_printer);
which lead to dark death (dark with the small blue LED glowing slightly) on the core. I changed it to just defining the pointer and then initializing with new in the setup loop (with minor modifications to a few things):
cdam::Printer *_printer;
cdam::StoryLoad *_storyLoad;
followed by
void setup {
_printer = new cdam::Printer();
_storyLoad = new cdam::StoryLoad(_printer);
}
which has gotten me out of the dark death, and includes a rapid succession of red (not orange) blinks on start up, followed by what appears to be a reset, and then breathing cyan. At this point the code does not appear to be running, and it won’t show up on serial. Here is a short vine of startup through red: https://vine.co/v/MZJPEYKTTgM
Again, this same code was working fine up until a recent pull. I can try and track down which commit appears to be the cause.
@choosatron would be helpful to know what commit caused the issues, if you could help us identify the cause of the problem! I wonder if you might be running out of RAM?
I should be able to track down the commit this afternoon, at least get closer to the cause. I shouldn’t be running out of ram unless the Spark firmware had a huge spike in ram usage. We’ll see!
1 Like
Ok! So three issues I’ve made progress on here:
-
Red Flashing
-
Dark Death
-
1 Minute Death
-
First, the issues with flashing red are not related to the Spark firmware, but the dark death is. After changing my initializations to pointers, and initializing in setup, I had the flashing red issue, which was because in my frantic changes to track down the dark death issue, I have a function call trying to access initialized variables. The red flashing was a red herring.
-
The dark death, however, is real. It appears to be caused by initializing variables / classes outside of the setup method or loop, instead of just creating a pointer and initializing in setup, which is how I fixed it above. This issue exists in the latest firmware. If I reverted core-firmware to revision 45a41ad - on January 23, core-common-lib to revision 21ca0c4 - on January 24, and core-communication-lib to revision b03f9c1 - on January 31. The dates are arbitrary, selected as being the closest to when I remember it working. Plus I needed to make sure all three repos would build together. I need to move forward, so won’t be investigating this further (since switching to pointers initialized in setup bypassed the issue), though I’m happy to help if there are specific actions I can take for you.
-
My original problem, which is everything ‘dying’ at exactly one minute from startup, still exists, and I have no idea what is causing this. Exactly 60 seconds from power on (not wifi connection being established / main loop running), the code loop stops. The Spark Core does not change visibly (still breathing cyan).
Are there ANY ideas what could be causing this 1 minute death? It is such a specific time, and again, begins at power on…
60 seconds sounds like it wants to be a configured timer / timeout value. Are you opening / relying on alternate sockets that aren't being maintained maybe?
edit: what are we calling "the dark death" (great name btw). Is that RGB LED dim and D7 on?