Hey Guys!
I just wanted to reach out to any users that are having trouble getting their cores online. If your core connected to your wifi, but is fast blinking cyan forever (not green), please post here, or message me with your core id.
These steps might also be helpful:
To clarify: If your core has ever made it to ‘breathing cyan’ please ignore this post.
Thanks!
David
Just wanted to say, that this fast cyan can be caused with too much memory allocation on global variables in user app.
For example this code will get you Core to state that can only be fixed with factory reset, or local dfu-util flash with nicer code.
char tmp[4096];
void setup() {
}
void loop() {
}
A great way to waste 3-5 hours while debugging the main code elsewhere and forgetting that temp array you added with many lines of other code.
Good call! I wonder if this improvement would help prevent these kind of heartaches in the future?
@Dave my core was working fine at my sister’s house. Then I came home and connected it to my WiFi and I am getting ‘fast cyan’ blinking. It won’t connect. My core id is 53ff6b065067544830340187
@Dave what @weakset is saying is that something as simple as allocating 4Ki of memory for a character array crashes something in the Core. In fact, I saw this same thing last night with a 2Ki buffer. That’s not going to eat up all of the 17KB or so that are available… so you won’t perceive it as a red flag.
So there is something else happening that’s an issue, maybe with the compiler? We should be able to define a 10Ki buffer if we want, right?
Exactly, but I’m not sure if there is necessarily anything wrong. Just something easy to miss even by experienced coder.
When coding PC software, I tend to throw in bigger than necessary temp variables to test stuff. Too small may cause problems, but with PC there is almost infinite amount available (and it can swap to hard disk if you make something really foolish.) 4K did feel good amount to thrown in with 20K total in Core.
The catch with Core is that user app isn’t actually an app. It is two funtions that is called from hidden main app. I have heard people to refer this hidden part as separate firmware, but they are actually coding a small portion of firmware themselves.
Tinker source even says:
/* This function loops forever --------------------------------------------*/
void loop()
{
//This will run in a loop
}
In reality that function doesn’t loop forever, but runs repeatedly.
And here comes this fast cyan problem:
It appears as if only the hidden firmware is still running and reaching the Cloud. It is easy to thing that in this point nothing you have written is even loaded to anywhere.
But actually those variables and constants outside loop() or any other your function have been allocated to memory and this leaves the Core less memory available to do its Cloud stuff etc.
If you declare variables inside the functions, they are released after loop() is finished. For example Core can handle this without hanging up:
#include "application.h"
void setup() {
//Initialize serial and wait for port to open:
Serial.begin(9600);
while(!Serial.available());
}
char done = 0;
void loop() {
char banana[1024*10];
if(done==0){
for(long i=0; i<(1024*10);i++){
banana[i]=i%256;
}
for(long i=0; i<(1024*10);i++){
Serial.print((int)banana[i]);
Serial.print(",");
delayMicroseconds(200);
}
done++;
}
}
That is 10K filled up and verified in the first time loop() runs. The first example hangs up somewhere ~2.6K.
Ahh interesting. Just having large-enough globals defined in the user firmware can interfere. This might bring us back to the RTOS / context-switching discussion that was happening in other threads, or I wonder if there might be a way to run user-firmware as a wholly separate application. – That might not make sense from a firmware point of view, just a thought.
I do think that presenting how much free ram / headroom is available, or warning if there isn’t enough free to do the handshake, would prevent some of these headaches. The core does have 20k of ram, but I think something like the lower 10k is occupied by networking and encrypted handshake overhead. I think too that space is shared between the stack and the heap, so it’s not as much as those of us in desktop-land are used to. 
Hi @aamirjvm,
Can you try clearing the wifi profiles, and smart config-ing it again? http://docs.spark.io/#/connect/troubleshooting-step-3-reboot-and-clear-memory
Thanks!
David
So why exactly if we have at least let’s say only 8Ki of free RAM, would a 3Ki global buffer hang up the Core, whereas a 7Ki buffer defined locally in loop() does not? I’m not seeing how bouncing back and fourth really fast between the B/G tasks and user tasks is the answer here.
I’m guessing probably that the initialization and handshake need to allocate and free a chunk of memory, which is released when they’re done. Something that isn’t used until a user-function is called would be safe since that would happen after the handshake, where a global would prevent that memory from being available in the first place?
Holy crap how big is this handshake? xD
omg such giant 
's 
I think a big part of the giant size has to do with some requirements of the public-key encryption routines. We’re using an embedded library for that stuff, but it’s still pretty huge. We’ve been talking about how we can free that memory back up.
Any idea about specifically how big it takes at it’s biggest point?
That would be a good question for @zachary or @satishgn – I don’t know offhand yet, but I think those guys would know
Hi @Dave, I have tried clearing WiFi profiles and redoing smart config from iPhone 4 several times, with no success. I also did a factory reset, same results - fast cyan flashing. When WiFi has been configured, it goes very quickly from blue, to flashing green, to fast cyan flashing … So I guess this means that firmware has gotten passed the WiFi router login and is struggling with the cloud connection?
Thanks
Hi @aamirjvm,
Hmm, yes, fast cyan should indicate that the core is on your network, but it’s having trouble establishing a connection to the server. This could be because a router or firewall is blocking the connection, or it can be because keys on the core aren’t working. Unless you wiped your external flash memory recently, I’m guessing something on your network is blocking your core.
HI @Dave, the problem seems to have resolved itself. I enabled “Hot Spot” on my iPhone, and then configured the Spark Core using USB serial terminal. This worked and the core was able to connect to the cloud, and then it started flashing purple which I think is a firmware update. Then I erased WiFi passwords and setup the Spark Core on my home WiFi router using the iPhone app and everything works fine now.
@aamirjvm I have seen this kind of behavior with networks that have a ‘captive portal’, as an example; the Core attempts to connect to the Cloud and gets intercepted by something else, and tries to do the encrypted handshake with whatever thing got in the way, and just gets stuck. In my case I was able to recover by re-starting, and the captive portal let the Core through the second time. We should write some code to timeout and re-attempt if this happens.
@zach Yesterday night I arrived home and my core was flashing fast cyan, I guess for some reason it re-started and had a handshake problem. I was just curious and left it the whole night and in the morning it was the same, I’m guessing it’s not restarting or timing out, it would be a nice thing to add!
It sounds like you have unfortunately encountered the CFOD (Cyan Flash Of Death). Good news is you’re not alone and forces have been mobilized to fix it 