Photon setup flashing cyan with a "quick red burst" (now orange burst) [Solved]

@Ashton, if you don’t mind, can you tell me how you fixed the keys issues? So that i have some idea of what users are doing when things fail.

Thanks! :wink:

Just wanted to let everyone know that apparently keys can get corrupted at brown outs. I tried running
my Photon directly off a 10W USB solar charger that is one of the simple ones where it outputs voltage even if it doesn’t get 5V. It reset a few times and I wanted to see whether it would boot once the sun is out from the clouds. After that it first
only flashed blue, then I set up the WiFi and it flashed cyan with intermittent red. Reflashed the 0.4.3 firmware but that
didn’t help. Then I regenerated the key and sent it to the cloud and that finally did the trick.


Could you help why I get this error?

C:\Users\Amir\Downloads>dfu-util -d 2b04:d006 -a 1 -s 2082 -D cloud_public.der
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 2b04:d006
Run-time device DFU version 011a
Claiming USB DFU Interface...
Cannot claim interface

Are you using a USB3.0 port?

I use a USB2 port.

I suddenly tonight am having this issue with three Photons that had previously connected to the cloud and were previously working fine… I normally have them operating in SEMI_AUTOMATIC mode (connecting to Wi-Fi but not the cloud), but went to connect one of them to the cloud to re-flash. Instead of connecting successfully like normal it flickered cyan with red bursts. I thought something must have happened to this Photon so I tried one of my other ones, and it did the same thing! Then another! All in the same night… I have a big meeting tomorrow so this is horrible timing, and I can’t seem to get dfu-util to work to try new keys, I keep getting “No DFU capable USB device available” even though I have installed the drivers with Zadig and have the Photon in DFU mode. Any ideas how I can fix this with my Photons ASAP!??

I was able to update the keys and get rid of the red bursts by switching to a Mac (instead of my Windows machine) which was able to recognize the Photon in DFU mode, then following the steps provided by @mdma here. But what the heck could have caused this?

This often doesn’t help ;):

There are so many odd quirks in Windows that can seriously mess up pretty much anything, itself included. Try uninstalling all the particle drivers, and installing them again. That might help. Using different USB ports/cables can also make a difference.
As to what may have causes the red bursts, not really sure…

Wow that’s terrible luck to have all 3 fail, sorry for that. If you’re able to reproduce the problem I’d love to know how so we can investigate.

If it happens again, please make a dump of the memory using this command (with the device in DFU mode), and send me the resulting file:

dfu-util -d 2b04:d006 -a 0 -s 0x8000000:0x100000 -U dump.bin



I have the exact same problem and have tried everything in this thread. I have made a dump of the memory, where should I send it?


Thanks @mdma, if I encounter the issue again I will try to note the specific steps leading to it. I’ll also save the memory dump file and send it your way! One strange thing to note from what happened to me Monday night is that the third Photon I tried wasn’t even running the same firmware as the other two when I connected it to the cloud and saw the cyan flashing with red bursts.

1 Like

I have recently experienced the same problem as described in this thread. After ‘reseting’ the keys, my Photon is recognized as ‘online’ in the developer Dashboard, but it is not properly recognized in the Android App or the Web IDE.

I started experiencing this problem with all of my devices: 2x Photons and 1x Core. (although, I don’t spend much time troubleshooting the Core)

!!! Exclamation points!

I put my Photon in my project after it was working flawlessly and I got these gem. Been at this for hours trying to cobble together sending the key to the cloud. (Installed CLI, then DFU was down…, factory reset, then the Photon refused to show up under the USB utility, then again, then dfu was in the wrong directory, then all the base belong to cloud…)

I have been having the same problem as the above post before this happened and it did it with every single device. Every single one showed up, but would not Tinker or Build flash…

I am stuck trying to dump my key right now, it looks like it isn’t liking openSSL. I grabbed the utility and followed the thread on installing all the goodies… Is there some way to manually run the command that is failing?

Make sure you install OpenSSL on Windows:
Win32 OpenSSL v1.0.2d Light should work.

When you run the keys save command, you have to delete the previous file there because it will not overwrite it by default. See how it’s saying the file already exists, add the --force flag? You can specify the force flag or just create a new name or delete the previous files. Here’s a run through:

✶brett✶ ~/code/firmware/modules $ particle keys save mykey
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U mykey.der
running openssl rsa -in mykey.der -inform DER -pubout  -out

✶brett✶ ~/code/firmware/modules $ particle keys save mykey1
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U mykey1.der
running openssl rsa -in mykey1.der -inform DER -pubout  -out

✶brett✶ ~/code/firmware/modules $ particle keys save mykey
This file already exists, please specify a different file, or use the --force flag.

✶brett✶ ~/code/firmware/modules $ particle keys save mykey --force
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U mykey.der
running openssl rsa -in mykey.der -inform DER -pubout  -out

When you send the keys you use the device id or device name, so something like:
particle keys send myphoton2
particle keys send 123412341234123412341234

I am curious. Did all of your devices start mis-behaving at the same time? … That seemed to happen to me, as well.

Let me know if you find a solution. I have successfully ‘saved and sent’ my keys. However, this did not completely solved my problems (as I described above).

Looks like openSSL is being a tool. Installed it 4 times, and registered the environmental variables several times.

Can someone give me the variables to check against just in case?

Also is there a way to manually call the path to openSSL in a command or provide Node.js where the path is?

Yes, but all but the device I am attempting to fix decided to come back a few hours later. It is like this device was the straw the broke the camel’s back. Other than the wait time, spending 5 hours messing with it just isn’t worth 19 dollars. I unsoldered it and removed it from my project (a pain in the…), then had a German keyboard kid style talk with it. Being up 15 hours then having defiant parts isn’t allowed. (Just to be clear, I didn’t damage it)

I bought 2 cores, 7 Photons, and 2 electrons because I figured something like this would happen. I just hope the software engineers have some way to find and reset these keys for larger commercial customers. The process has a few holes in it that needs a bit of documentation updating, but remember support for this product is built into that 19 dollar cost… I don’t think I have the right to complain to much there…

1 Like

I ‘think’ I might have soled my problem. My Photons were part of a ‘product’ that was scheduled for automatic OTA firmware flashes. And for whatever reason, this was messing things up. (Maybe my firmware was ‘bad’)

How did you fix that? Did you go into “yellow mode”? I got all mine but the one to work now with a simple factory reset.

Yellow blinking is DFU mode -