My core never gets to breathing cyan, it's only ever 'fast cyan'

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?


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.

1 Like

@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.

1 Like

@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 :smile:

Finally we meet. I thought I had escaped from it. Until last compile-server2 I never had it, interesting.

There is a difference between CFOD (slow) and CFOD (fast) right? I don’t get the typical slow CFOD… but I have seen the fast CFOD when I mess up things in my code, like allocate too much global memory.

1 Like

I think ‘Fast cyan’ is the core trying to complete the handshake with the server once the socket is open, and ‘slow cyan’ is the core trying to establish the socket in the first place.

1 Like

@Iv4n @BDub The biggest memory usage is definitely in the RSA handshake. Darn that big number math. The price we pay for security. :wink: I don’t recall how much heap it claims max, but it’s the bulk of the ~10K claimed by :spark:. Here are some pointers to relevant code for anyone who feels like digging into memory usage improvements.

The only call to allocate heap (malloc) in the entire firmware is in TropicSSL’s mpi_grow:

This gets called in init_rsa_context_with_public_key when we send the initial message encrypted for the server:

It’s also called (init_rsa_context_with_private_key) when the Core is processing the encrypted reply from the server in set_key, both in decipher_aes_credentials and verify_signature:

Our malloc/free implementation is extremely simplistic right now and does not handle fragmentation. See our stub for _sbrk:

As I write this I’m noticing that the description for mallopt in the newlib docs says:

… releasing it back to the system in free (the space is released by calling _sbrk_r with a negative argument)

We have a stub for _sbrk but not one for _sbrk_r, though this might all be delegated under the hood. If you know otherwise, by all means submit a PR.

As always, pull requests welcome. @satishgn has been working lately on trying to statically allocate a buffer for the RSA math and free it up afterward. Not there yet, but we’ve got our eyes on the prize.

1 Like

oic. nevermind, wrong CFOD i guess. good luck solving whichever one it is!

Core id is 55ff6c064989495317402587. Always fast blinking cyan. I haven’t even had a chance to claim my id…

Hi @war1st ,

I haven’t seen your core try to connect to the server in the last week or so. It’s possible it has a bad copy of the server public key. Can you re-flash that key and see if that helps? Grab dfu-util binaries from here: or with brew / macports if you’re on a mac, and then:

grab this file
dfu-util -d 1d50:607f -a 1 -s 0x00001000 -v -D cloud_public.der

Make sure you’re using dfu-util version 0.7, and not the earlier ones.


I reflashed my core with the new cloud_public.der successfully, but the problem stays.

Filter on vendor = 0x1d50 product = 0x607f Opening DFU capable USB device... ID 1d50:607f Run-time device DFU version 011a Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=1, name="@SPI Flash : SST25x/0x00000000/512*04Kg" Claiming USB DFU Interface... Setting Alternate Setting #1 ... Determining device status: state = dfuERROR, status = 10 dfuERROR, clearing status Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 011a Device returned transfer size 1024 No valid DFU suffix signature Warning: File has no DFU suffix DfuSe interface name: "SPI Flash : SST25x" Memory segment at 0x00000000 512 x 4096 = 2097152 (rew) Downloading to address = 0x00001000, size = 294 Poll timeout 50 ms Download from image offset 00000000 to memory 00001000-00001125, size 294 Poll timeout 30 ms File downloaded successfully

@war1st So the :spark: core has never connected to the cloud i suppose?

Does it get detected by the Spark app you use to send the wifi credentials?

Sorry i’ll ask some questions but all to make it faster to resolve your issue.

  1. Router settings - Type? WPA/WEP? Channel Number?

  2. Try factory reset and resend your Wifi credentials are let us know the light status

@kennethlimcp Yep the core has never connected.

  1. Sometimes Spark app detects my core (the core connects to the router), sometimes not, anyway I use CoolTerm app.
  2. Router Air Port Time capsule II 2.4 GHZ, WPA, channel 6 (I’ve checked everything (or almost) that was in FAQ before posting here :smile: )
  3. I’ve tried it already.

So you basically entered the credentials using USB.

Can you try using the Spark/TI App and see if anything shows up after the Wifi Credentials are pushed to the core via Wifi?

I’m thinking that the Original firmware might be causing and issue for the lock-up at the last stage to get connected. Since your core never ever got connected. Really just a wild logical guess.

dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin


Testing connecting the core to another network

Another fix i thought of is the private key based on this post: (but highly impossible, right? @Dave)


I think we haven’t seen @war1st’s core id pop up on the server side logs yet, so you’re right in that it seems unlikely that the private key is the problem. I’m guessing issues connecting to wifi at this point, or maybe that port is blocked on that network?

@kennethlimcp Ok,I upgraded firmware, now it really looks like core can’t connect to my router. It cycles fast cyan-fast green now. Basically my network consists of 2 routers - Apple Wi-Fi and Thomson TOW 770 (DOCSIS 3.0). The last one connects me to the Internet. @Dave Never thought about it,as I tried the Core with different networks and the result was always the same - fast blinking cyan. :frowning:

Okay, that’s good to know! If you haven’t yet, can we try running the patch programmer? This is just like flashing new firmware, just after you flash you hold the Mode button for 3+ seconds until it starts flashing magenta.

You can grab the binary here:

And instructions are here;