Troubleshooting: My Core is flashing yellow/red lights after it connects to wifi

Hey Guys!

In case anyone is having trouble connecting to the cloud and you see this problem, and it doesn’t go away after a few minutes, please reach out to us at I will be releasing a fix for this soon.


1 Like

Hey all,

In theory, the fast blinking orange error light after connecting to Wifi is the core telling us that a decryption error happened during the handshake with the cloud. Although I lost a lot of sleep worrying about this issue, it looks like a few cores (about half of 1% based on our logs) snuck through the manufacturing process. If you want, the process for fixing this is also the process for generating a new private key for your core. It’s a two part process that I’ll be posting friendlier tools and docs for, but if you wanted to get going in the meantime, hopefully this will help:

Instructions for generating and flashing a new private key

*Note! - It’s very important you only follow these steps if you’re seeing this issue, or if you want to change your core’s private key. Unless you send us your new public key, or restore to the previous key, your core will lose the ability to connect to the cloud after performing these steps. *

###Note! If your core has ever reached “breathing cyan” you probably don’t need to follow these steps since your keys were working.

##There is a tool to help you do this, but you still have to install a few things (including dfu-util, and openssl, sorry!), details here:

##How to refresh your keys manually

1.) Install dfu-util from here:

2.) Connect your core and put it into DFU mode

Hold down both buttons and release the 'reset' button.  Hold down for 3+ seconds, the light should blink yellow.

3.) run the following and verify [1d50:607f] shows up somewhere

dfu-util -l

4.) Install Openssl, or the encryption suite of your choice

For Windows: instructions on SSL
Windows binaries download:
5.) Generate new keys for your core:

openssl genrsa -out core.pem 1024
openssl rsa -in core.pem -pubout -out core_public.pem
openssl rsa -in core.pem -outform DER -out core_private.der

6.) backup your previous key (hey, just in case)

    dfu-util -d 1d50:607f -a 1 -s 0x00002000:4096 -v -U old_core_private_key.der

7.) connect your core in DFU mode, and copy the private key to your core:

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

8.) (*optional) update the server public key:

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

9.) connect to your core over serial, and hit ‘i’ to get your core id

10.) Please send me your core’s public key to the cloud using the spark-cli ( ) with:

spark login
spark keys send your_core_id core_public.pem

If that doesn’t work send us your core id and public key to

Footnote - Running on mac/linux? try sudo dfu-util, Running on Windows? try: dfu-util in an admin command prompt

*Another Footnote - If you see something like “Failed to write whole chunk: -7 of” There is a quirk that dfu only likes to write keys that are an even number of bytes. You can also pad an odd length key with a random byte at the end as well. *



Mac users can install dfu-util with Homebrew.

brew install dfu-util
1 Like

Just wondering - has anyone done this using a windows (7) machine ?

I’m very close but just can’t get dfu-util to see the core. (step 3) I can see it from zadig and have checked/ installed drivers but still no go.


I have run dfu-util on Windows 7, try opening up the command prompt as administrator.
Also don’t forget to check the device manager for incorrectly installed drivers (It happened to me)

Windows 7 DFU-Util

1 Like

I had a driver issue too but I think I fixed that.
The Core appears under 'Universal Serial Bus devices as CORE DFU in device manager and has a driver from 02/06/2012 version 6.1.7600.16385
Driver Files

  • is that the same with you ?

I wonder if it’s a Win7 64 bit issue. Are you 64 bit ?
I am running cmd prompt as administrator.

I can’t confirm any drivers until I get home, but I am using Windows 7 x64.

Looks like the drivers match up

Drivers #1

Drivers #2

Thanks for checking and all your help.

I was about to give up and had tried both USB on the front of my PC and I thought I’ll just try one on the back - and this time it worked. No idea why , but I’m a happy bunny now. Hopefully even happier once I get the keys swapped.

1 Like

It’s been a long journey but I’m up and running.

One extra bit of info. In step (5) above when you generate your private key make sure it’s an even length (file size shown in directory listing) otherwise it wont upload to the core in step (7) and you will see this message and the core will come out of DFU mode.

Downloading to address = 0x00002000, size = 609
Download from image offset 00000000 to memory 00002000-00002260, size 609
Error during download get_status
Failed to write whole chunk: -7 of 609 bytes

If it is an odd length then just repeat step (5) to regenerate your keys until you do get one that is even length and then you’ll get this in step (7)

Downloading to address = 0x00002000, size = 608
Download from image offset 00000000 to memory 00002000-0000225f, size 608
File downloaded successfully



Thanks everybody for your efforts!

I think I have that problem :frowning:
Just sent a note after following the above instructions.


This might also help windows users:

Before step 6, I would add step 1.4 Zatig from this post

For step 8, instead additional details can be found here:

Have a nice day,

so for us that has this problem. Are you sending us a new Spark Core?

Hi @sjunnesson,

The orange blinking problem indicates that the keys on the core need to be updated, but otherwise the hardware on the core is perfectly intact. It’s possible to fix this problem at home quickly, and we’re working on a command line tool that will make it even easier. If you’d rather go the replacement core route, we can certainly do an exchange instead, but there is some delay involved due to very low availability.


I will put it in the pile of Cores to use later, have 20 of them so have spares. Please ping me directly when the tool comes available.

Sure thing, I gave myself a task in our task tracker to ping you when it’s ready. :slight_smile:

I’ve now got a core that won’t connect to the cloud - get’s stuck in the last rapid cyan flashing (cloud handshake?).

When I try to save the old PK, with

dfu-util -d 1d50:607f -a 1 -s 0x00002000 -v -U old_core_private_key.der

It looks like it’s trying to dump all memory, which doesn’t seem right:

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
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuUPLOAD-IDLE, status = 0
aborting previous incomplete transfer
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "SPI Flash : SST25x"
Memory segment at 0x00000000 512 x 4096 = 2097152 (rew)
Limiting upload to end of memory segment, 2088960 bytes
   Poll timeout 30 ms
Starting upload: [#####################

This continues for a long time.

I’ll try making a new private key, although any other tips you have appreciated.

Ahh, if you add “:size” to your request it’ll limit how much it’s pulling down. I generated a new der file locally, and it was 609 bytes, but I don’t remember offhand if that changes (I think it does). It’s trickier to read out for that reason that’s why I’ve been recommending writing new keys. :slight_smile:

dfu-util -d 1d50:607f -a 1 -s 0x00002000:609 -v -U old_core_private_key.der

Is it possible for this to still be happening on units shipping out now? I just got mine a couple days ago, and after it connects to wifi, there is fast flashing cyan, followed by fast flashing red.

After a while it will go back to fast flashing cyan and repeat the cycle.