Spark core flashing fast cyan after wifi connection, unavailable via

I’m having a problem with a spark core chip antenna model. I last used it sometime last year (at that time I successfully programmed it via the web interface) and don’t remember what state I left it in so I’ve downloaded the spark-cli tool set and have attempted to restore it to factory defaults by following the article titled ‘Perform a Full Firmware Upgrade’. My spark-cli is up to date as of this posting and spark --version reports 1.0.0.

I placed the device in DFU mode by pressing both buttons, releasing reset and continuing to hold mode until the multicolor LED started blinking yellow at a medium pace. At this time the faint blue LED near the USB connector is also lit.

I then issue
spark flash --factory tinker
During which time the blinking yellow slows slightly. After spark flash command indicates ‘File downloaded successfully’ and the multicolor LED immediately returns to blinking yellow at a medium pace, no reboot happens.

I then issue
spark flash --usb cc3000
During which time the blinking yellow slows slightly. After the spark flash command indicates ‘File downloaded successfully’ the multicolor LED begins to blink slowly magenta. After blinking magenta it goes solid green, solid blue and then back to medium yellow. The faint blue LED is still lit.

I then issue
spark flash --usb tinker
During which time the blinking yellow slows slightly. After the spark flash command indicates ‘File downloaded successfully’ the multicolor LED breathes white once and then flahes blue.

I then issue
spark setup
The cli proceeds to ask for my SSID, security mode and passphrase. After I enter them the multicolor LED goes off, then solid blue, then solid green, then medium blinking green. At this time I see the spark core issue a DHCP request and start to send multicast traffic on my LAN using the address the DHCP server gives it. The multicolor LED then starts blinking very quickly white (using the green and blue diode segments) with an occasional fast single blink containing just the red diode segment. If left for an extended period of time, just the red segment of the multicolor LED blinks quickly for several seconds, then the unit returns to blinking apparently white (green and blue segments) with the occasional red segment. The unit will never proceed to breathe blue but it does continue sending multicast traffic on my LAN. Needless to say, the build portal at says ‘Could not claim core’ when I try to claim my core. In testing, I previously removed the core from my account.

I’ve also tried performing a “Deep update” as suggested in the spark-cli guide. After the update, the spark core reboots and behaves as described above. I’ve tried spark keys doctor too with the same results.

At this point, I can hold the mode button to get the blinking blue LED and redo the setup. I can also easily reenter DFU. If I attempt to do a factory reset, the multicolor LED goes from blinking yellow to blinking white to solid white back to blinking white. The reset appears successful and I’m left with a blinking blue LED and am able to redo the spark setup. I’m at a loss as to where to go from here. I can try to setup the Raspberry PI JTAG adapter mentioned elsewhere on the forums if anyone thinks it would be beneficial. That said, I’d need some guidance as to what to do after it is setup.

The spark core behaves the same when plugged in to a 5V 2A adapter and the PC I’ve been using to use the spark-cli. Also, I’ve left it plugged in for several hours and it remains in the same state.

Additional info:
Router: WNDR3700v3 running stock firmware with only the spark core connected wirelessly
Security: None
ISP: Comcast Residential Cable
Modem: Motorola SB6120

I’ve also tried two other wireless routers running DD-WRT and had no success.

I’ve been unable to find these symptoms described elsewhere on the forums and would appreciate some help.

Thanks for your time!

Did you ever connect to the :cloud: successfully (breathing cyan) before?

what channel is your router on and is it 2.4ghz?

Any other colours beside flashing white? It should hit flashing green…

It sounds like your white is actually cyan - green and blue mixed. This is the color when the device tries to connect to the cloud. The intermittent red flash indicates a connection error - it seems the core has connected to the router, but cannot connect to the internet.

Any steps you can take to validate the internet connection from the router, such as checking the gateway IP would be my next step.


1 Like

Yep, well over a year ago I used this particular spark core successfully with the :cloud: via

I’ve tried the following routers and configs all in the 2.4Ghz band:
BG-mixed mode router running DD-WRT on channel 1 with both no security and WPA2 security
G only mode router (different make model than above) running DD-WRT on channel 5 with WPA2 security
BGN-mixed mode running Netgear stock firmware on channel 6 with no security

I’m confident that my core has gotten on at least my network with all three routers because in all cases I see my DHCP server hand it an address and then I see it send multicast traffic on my LAN.

Upon power up the core is bright white, then quickly fades and becomes flashing green. While it is flashing green I see it send/receive data on my network. It goes from flashing green to very quickly flashing white (green and blue diode segments) and occasionally red.
(I started this reply last night and most of it is immaterial due to today’s revelations but I left it so as to address @kennethlimcp response).

I took some time today to replace my router with a maching running pfSense. This has allowed me to perform packet capture on my routing device. As such, I’m now able to see that my core is in fact making DNS requests for, getting an address ( and then successfully completing a three way handshake with that server. After the three way handshake, the core sends three packets which wireshark decodes as protocol CoAP but wireshark’s ‘expert info’ feature lists all three packets as being malformed with the summary ‘option longer than package’. After the three packets and their ACKs come in, sends a FIN,ACK and the connection seems to be torn down without errors. Then the the cycle starts again.

Any suggestions as to where to go from here? If it would help anyone, I will happily provide a pcap file of the described flow.



to resolve this faster, could you simply post a video of the led sequence for us to quickly debug?

That will save us a lot of guessing! :wink:


As requested, here is a video of the multicolor LED during powerup.

I think @mdma was right, it looks like cyan to me in the video whereas in person I would have sworn it to be white.


Kinda hard to tell actually

I see white following by a long flashing green before a blinking cyan and a couple of red flashes.

Seems like… unable to connect to the internet or bad server public keys

I’ve run 'spark keys doctor ’ a few different times and it reports to have downloaded the new key to the core and uploaded the new key to successfully.

With the aforementioned packet trace showing a successful three way handshake, sending CoAP packets, seeing ACKs for them and the error free RST,ACK sequence I’m confident that the core is in fact talking to I am concerned that wireshark thinks my core is sending malformed CoAP packets, but that may be a side effect of the core’s encryption; I haven’t studied the implementation enough to know for sure.


So i presumed you want spark keys doctor CORE_ID in DFU mode?

What happens if you keep it running? What is the light sequence?

Correct, I issued spark keys doctor CORE_ID when the the core was in DFU mode.

I left the core running all afternoon today and it’s still doing the cyan (what I previously referred to as white - LED segments yellow and blue) blink with the occasional single red LED. It will occasionally blink several single reds in a row (sometimes several seconds worth) and then immediately go back to flashing the cyan/white, but I don’t have the exact interval/duration of this as it doesn’t seem to happen predictably.

It would be nice if there was some way I could see the logs generated on to see what spark’s server thinks about my devices connection as I’m at a loss.

I’ve found the memory map for the spark core and I see that there is 1024B of reserved space for System Flags at 0x08004C00. I went ahead and used dfu-util to store those bytes to a file and upon examination all but 4 bytes of those 1024 are 0xFF. I haven’t yet found anything that documents what exactly is supposed to be in System Flags, is there a mechanism I can use to ensure that my System Flags are what they need to be?

For reference, here is the command I used to read System Flags:
dfu-util -d 1d50:607f -a 0 -s 0x08004c00:1024 -U systemflags

Well, I’ve fixed my problem.At some point in time I must have typed in an incorrect address for dfu-util and inadvertently overwritten something I didn’t intend to. When reading about how the bootloader works ( I noticed that the spark core has to have the server public key to be able to work correctly. For curiosity’s sake, I downloaded the key linked from that site and diff’d it with the key I copied out of my core with:

dfu-util -d 1d50:607f -a 1 -s 0x00001000:402 -v -U cloud_public.der.myspark

They didn’t match so I put my core in DFU and programmed the server’s public key as directed. Upon reboot I immediately got breathing cyan, I was able to claim the core and have successfully programmed it with

Is there any reason the server’s public key isn’t verified by the spark keys doctor command?

Thanks again for your help!

1 Like

Hi all,

I have a also a Spark Core Chip Antenna. I never got to set the WiFi through the Android App, but I was able to do it through the USB and particle-cli.

But then it happened the same problem that it stays at the cyan blinking state. I tried to update the firmware using “npm update -g particle-cli && particle update”, but it said that I had the latest version.

I upgraded the firmware using “particle flash --factory tinker”, “particle flash --usb cc3000” and “particle flash --usb” and it did exactly the same afterwards.

Could it be an issue with the public key? How can I change that?

I would really appreciate any help.


@imanolgo I haven’t done much with the core since my last post so I’m not sure if anything relating to the server public key changed after the Spark->Particle transition.

I see no harm in you trying what I did as long as you’re diligent about NOT unlocking and overwriting the bootloader (if you do so incorrectly you’ll no longer have access to DFU and end up with a “bricked” core). That said I wouldn’t spend any spend any time on the keys until after you’ve verified your Core is successfully communicating on the network and able to send and receive traffic from (or whatever the current URL is).

I would suggest before trying the below that you try

spark keys doctor CORE_ID
(or whatever the current command is since the name change) with the core in DFU mode as described by kennethlimcp above.

The problem I had was resolved by following the second step 3 listed here:
However, I think it is unlikely that you’re having the same problem I did unless you’ve been overwriting arbitrary memory locations (or trying alternate firmwares, etc) with DFU.

3. Grab the server public key, and flash it:

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

Good luck!