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


#61

Then it looks like it’s not in your path. Please see “Adding OpenSSL to Windows path” in the link above.


#62

OOOOhhh Kay, may have overlooked something here and really screwed things up. I found the guide to setting the path for Open SSL really confusing. But I managed to find the .bin directory and run a command prompt from there - entering your suggested “particle keys new” and got the response “new keys created” I then realised this is the approach if you have NEVER had the unit connected to the cloud. Mine has - for some time. Have I “bricked” it?


#63

Not bricked, you should be fine, just be sure to also run particle keys send with the new keys so the cloud accepts the new keys from the device. (There’s a post about that further up.)


#64

I had a working Photon and was trying to integrate a Super Cap to provide a power off alert via a webhook - my problem occurred after the Cap slowly discharged VIN, so I guess pretty much the same as a brown-out


#65

Thanks a lot for your advice - much appreciated. But seems a bit beyond me - nothing I try seems to work. I think my biggest problem is getting the OpenSSL to work “globally” - and retrieving the key. I ran Kenneths suggested process for updating the public key and that seemed to work - but same outcome (flash red). Will have another go soon.


#66

Please also try updating the server public key, since that might have changed too:

// grab this file https://s3.amazonaws.com/spark-website/cloud_public.der
particle keys server cloud_public.der

[Photon] Particle Android app error: "Setup process couldn't disconnect..."
#67

OK, managed to update that too - still no response. The terminal output is as follows:

C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>dfu-util -d 2b04:d006 -a 1 -s 2082 -D

cloud_public.d
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x2b04 product = 0xd006
No DFU capable USB device found

C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>dfu-util -d 2b04:d006 -a 1 -s 2082 -D

cloud_public.d
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x2b04 product = 0xd006
Opening DFU capable USB device… ID 2b04:d006
Run-time device DFU version 011a
Found DFU: [2b04:d006] devnum=0, cfg=1, intf=0, alt=1, name="@DCT Flash /0x00000000/01*016Kg"
Claiming USB DFU Interface…
Setting Alternate Setting #1
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
No valid DFU suffix signature
Warning: File has no DFU suffix
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000822, size = 402
.
File downloaded successfully

C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>particle keys server cloud_public.der
running dfu-util -l
Found DFU device 2b04:d006
checking file cloud_public.der
spawning dfu-util -d 2b04:d006 -a 1 -i 0 -s 2082 -D cloud_public.der
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Filter on vendor = 0x2b04 product = 0xd006
Opening DFU capable USB device… ID 2b04:d006
Run-time device DFU version 011a
Found DFU: [2b04:d006] devnum=0, cfg=1, intf=0, alt=1, name="@DCT Flash /0x00000000/01*016Kg"
Claiming USB DFU Interface…
Setting Alternate Setting #1
Determining device status: state = dfuDNLOAD-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 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000822, size = 402
.
File downloaded successfully
No valid DFU suffix signature
Warning: File has no DFU suffix
Okay! New keys in place, your device will not restart.

C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>^A


#68

What do you mean?


#69

Sorry, still getting the red flash


#70

I’m not sure why you have 3 copies of the same output above.

Here’s the full list of steps for completeness:

particle keys new
particle keys load device.pem
particle keys send <device_id> device.pub.pem

// grab this file https://s3.amazonaws.com/spark-website/cloud_public.der
particle keys server cloud_public.der

If you’ve done this and still getting a red flash then it’s not a keys problem but a connection issue.


Electron and general platform woes :(
#71

OK - will seek help with the Open SSL issue. If I run step 1 from the directory containing the OpenSSL bin, I get :
C:\OpenSSL-Win32\bin>particle keys new
running openssl genrsa -out device.pem 1024
running openssl rsa -in device.pem -pubout -out device.pub.pem
running openssl rsa -in device.pem -outform DER -out device.der
New Key Created!

If I go to step 2 in the same directory, I get

C:\OpenSSL-Win32\bin>particle keys load device.pem
running dfu-util -l
Error saving key to device… dfu-util is not installed

I see the files in the directory - but clearly no link to DFU. Probably a newbie prob - just not able to understand the guide to making the OpenSSL and DFU talk to each other.

Thanks for your patience. Will revisit in next couple of days.


#72

@DRCO, you need to add the folder where dfu-util is located in the windows PATH.


#73

Hi Peekay, I followed the guide as best I could and think I have both the OpenSSL and DFU in PATH. I followed the instructions to “force” the update when run from the DFU directory- but get this response on the command line:
C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>particle keys load device.pem
running dfu-util -l
Found DFU device 2b04:d006
This file already exists, please specify a different file, or use the --force flag.
Error saving key to device… This file already exists, please specify a different file, or use the --force flag.

C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>particle keys load device.pem --force
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_device.der
running openssl rsa -in pre_device.der -inform DER -pubout -out pre_device.pub.pem
Error saving key from device… Error: Command failed: ‘openssl’ is not recognized as an internal or external command,
operable program or batch file.

Error saving key to device… Error: Command failed: ‘openssl’ is not recognized as an internal or external command,
operable program or batch file.

C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32>


#74

@chris, don’t confuse the “System variables” from the path. These variables are used by the app whereas the PATH is used by the system to FIND the app. You will need to add the path for DFU and openSSL to the PATH user variable. You can add this to the end of PATH:

;C:\Users\CHRIS\Desktop\DFU\dfu-util-0.7-binaries\win32-mingw32;C:\OpenSSL-Win32\bin

Give that a shot. :smile:


#75

Hi,

Been spending 5 hours straight trying to fix this error that happened all of a sudden.
Re-flashed the cloud_public.der to my photon, no avail. Followed the steps below:

Step 1 performed, but device did not restart. Restarted manually, device now alternates bursts: cyan, then orange.
DFU mode again, performed step 2, got “New Key Created!” - Still, no auto-reboot. After manual reboot, same.
DFU mode again, performed step 3, got:
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der
Error saving key from device… Error: Command failed: C:\Windows\system32\cmd.e
xe /s /c "dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der"
File exists: Cannot open file pre_photon.der for writing

Error saving key to device… Error: Command failed: C:\Windows\system32\cmd.exe
/s /c "dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der"
File exists: Cannot open file pre_photon.der for writing

Performed step 4 regardless. Got: Please provide a filename for your device’s public key ending in .pub.pem
File exists, I am in the current directory where the file resides.

My device is alternating between cyan bursts and orange bursts. Please, please, please, help me. :-/


#76

Hi @wmoecke,

Here’s some tips to get you going:

  • You don’t need to restart the device in between each step.
  • Clear out any .der and .pem files that you have in the current directory, then run
particle keys server cloud_public.der
particle keys new photon
particle keys load photon.der
particle keys send **<device_id>** photon.pub.pem

Odd Electron flash patterns
#77

Ok.
Here’s what I’ve got after running step 3:

running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der
Error saving key from device… Error: Command failed: C:\Windows\system32\cmd.e
xe /s /c "dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der"
File exists: Cannot open file pre_photon.der for writing

Error saving key to device… Error: Command failed: C:\Windows\system32\cmd.exe
/s /c "dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der"
File exists: Cannot open file pre_photon.der for writing

I was puzzled. The message indicates that it seems to be a file already in the current directory and it cannot overwrite it. But I checked and there was no “pre_photon.der” file!
So I did a windows search for that file in my C: drive. Found it at “\VTRoot\HarddiskVolume3\Users\my_user\same\directory\structure\where\I\had\my\der\files”. Very strange. What does create this duplicate structure in the root of my C: drive??

Back to the main issue, deleted that one and ran step 3 again. This time, got:

running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -l
Found DFU device 2b04:d006
running dfu-util -d 2b04:d006 -a 1 -s 34:612 -U pre_photon.der
running openssl rsa -in pre_photon.der -inform DER -pubout -out pre_photon.pub.
pem
Error saving key from device… Error: Command failed: C:\Windows\system32\cmd.e
xe /s /c "openssl rsa -in pre_photon.der -inform DER -pubout -out pre_photon.pu
b.pem"
Error opening Private Key pre_photon.der
4816:error:02001002:system library:fopen:No such file or directory:.\crypto\bio
bss_file.c:398:fopen(‘pre_photon.der’,‘rb’)
4816:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:40
0:
unable to load Private Key

Error saving key to device… Error: Command failed: C:\Windows\system32\cmd.exe
/s /c "openssl rsa -in pre_photon.der -inform DER -pubout -out pre_photon.pub.
pem"
Error opening Private Key pre_photon.der
4816:error:02001002:system library:fopen:No such file or directory:.\crypto\bio
bss_file.c:398:fopen(‘pre_photon.der’,‘rb’)
4816:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:40
0:
unable to load Private Key

I’m out of ideas. And I saw that the “pre_photon.der” file was rewritten at that same weird directory structure - what gives!

I appreciate your late effort (dunno what time it is in California now, but here it’s 2:40am), but now I need to shut my eyes for a few hours before I come back here for another batch of attempts.

Thanks again, see you later!


#78

I think the openssl library is getting confused on windows. Let’s ping @nexxy who might be able to look into that when she can, and let’s look for an alternative route now.

Try this, from a more advanced shell like MinGW or git bash (regular DOS won’t cut it):

# make a file containing just the byte 255 (all ones)
echo -e -n "\xFF" > FF_file

# write this to the device to trigger new keys to be generated on-device
dfu-util -d 2b04:d006 -a 1 -s 34 -D FF_file

# this step is only needed if the device has previously connected to the cloud
particle keys send <device_id> photon.pub.pem

# reset the device

I hope that helps. I know it’s frustrating spending hours trying to get something working that is just working for most others, so thanks for your patience! :smile:

mat.


#79

From a Git bash window:

File was created successfully.

Got:

File too short for DFU suffix
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…
Setting Alternate Setting #1
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "DCT Flash "
Downloading to address = 0x00000022, size = 1
Download [=========================] 100% 1 bytes
Download done.
File downloaded successfully

Then:

Got:

attempting to add a new public key for device 370022001447343339383037
submitting public key succeeded!

Looking good so far - after a reset, device started flashing white. Held Setup and waited for it to (hopefully) flash blue, but instead it went into alternating bursts (cyan/orange) for a short time, then breathing purple (not necessarily bad, I see my photon listed as “active” in the Web IDE), so let’s see if I can flash something from the cloud.

No luck. But then I remembered [something else][1] that I keep stored in a separate folder, for cases when WW3 bursts out. This is something “someone” [posted a small procedure elsewhere on rescuing lost photons][2].
I reproduce their words of wisdom below:

So I did the following:

dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D reset.bin
dfu-util -d 2b04:d006 -a 0 -s 0x8020000:leave -D system_pad_BM-09.bin

And got my photon immediately back into breathing cyan state. Yaay. :smiley:

You guys absolutely rock. Big time. Van Halen style. Panama, baby. Haha.
(We’re engineers - patience, if not embedded in birth, has to develop over time - after a few occasional bursts of frustration)
[1]: https://github.com/spark/firmware/releases/tag/v0.4.1
[2]: Photon Initial Setup Error


#80

The extra steps were not necessary - breathing magenta is good - it’s connected to the cloud.

Flashing system_pad_BM-09.bin will be a very old version of firmware, it’s probably only breathing cyan because safe mode wasn’t coded as magenta at the time that firmware was built.

When breathing magenta you said no luck flashing from the cloud - what exactly happened there? The next step then should have been to flash tinker.

To get your device to a known state,please run these steps

npm install -g particle-cli
# put device in DFU mode
particle update
particle flash --usb tinker