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

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.

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

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>

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

2 Likes

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. :-/

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
1 Like

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!

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.

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]: Release modular photon firmware - 0.4.1 · particle-iot/device-os · GitHub
[2]: Photon Initial Setup Error - #47 by Carsten4207

1 Like

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

When I flashed from Particle Build web IDE, the code did not run - and the LED became breathing white.

After I got my photon to breathe the right color, I went straight to to here: http://www.cubetube.org/gallery/
Then I loaded one of my "visualizations" into my photon (running a 512 LED "cube") and I noticed it took a overwhelmingly longer amount of time (say, 15mins) under which, the photon alternated from flashing magenta to resetting, then back to flashing magenta a couple times - I am certain that it was updating its code from the cloud - but I have no idea of exactly what was being loaded (I suspect the most recent firmware and STM libraries?) and from which source (local to their own repo or particle's?).

So this is how I ended up. I am confident that now the photon is up-to-date, because it takes the usual few seconds to load any new code from that website, as well as from Particle Build.

I didn't know that for a while until after a week ago, I learned that this is good - after careful observation - whenever I set my photon to "safe mode" and it became breathing magenta, I thought something went wrong and proceeded to perform the extra 2 steps I mentioned above to get the breathing cyan mode back (to me, that was "safe").
I now know better, as whenever I put my photon in "safe mode" (releasing the Setup button during flashing magenta state) I can flash it and it becomes breathing cyan.

As users, we need to stick to what we know is good; speaking for myself, I know I've been late in catching up with the recent updates in the documentation, but - if I may offer my two cents of constructive criticism - I feel sometimes changes do take a while to make it into the official documentation, and although they are indeed good changes (e.g., when recently you guys pushed an update to 0.4.4), we usually get caught by surprise and it takes time to figure out what happened and (as it was the case with the 0.4.4 update) figure out what we need to modify in our firmware code to make it compliant again (e.g., with the push to 0.4.4 my code began issuing compiler errors due to a redefinition of two GPIO functions I've written directly, to cope with the lack of ReadInputDataBit() as well as STM32_Pin_Info* HAL_Pin_Map() STM32xx functions at the time - that is how I learned that I no longer needed them).

1 Like

@wmoecke, did you find the “Low level I/O” documentation section which describes the fast I/O functions like pinSetFast(), pinResetFast() and pinReadFast()?

With the HAL being finally deployed to all Particle devices, these commands remove the need for rolling your own and make code more portable. :smile:

Yep, peekay!
And I immediately saw a “brotherhoodship” with the macros:

uint8_t DIRECT_READ(uint8_t pin)
void DIRECT_WRITE_HIGH(uint8_t pin)
void DIRECT_WRITE_LOW(uint8_t pin)

I’ve been using these directly (copied the code I needed from the OneWire library) in my code prior to the 0.4.4 update. Now I no longer need them - how cool was that! :smiley:

(P.S.: peekay, I’m still waiting for that timer library you promised… :smile:)

@wmoecke, I know, I know!!! I had to figure out some issues with the Photon port and now I just need to document. Too much to do and too little time!!! :weary:

:stuck_out_tongue_closed_eyes:
Ah these users. They keep wanting twice what you give… :weary:

1 Like

Hi Peekay, Been out of town for a bit, so sorry for the delay getting back to you. Thanks for taking the time to literally, write the path addition for me - worked perfectly. Really, REALLY appreciated. I was able to complete the steps outlined by mdma - and I now have a working Photon again.

1 Like

Finally got a chance to try this - and with Peekay’s help Inow have a working Photon again. Thanks for help and your patience

2 Likes

I am seeing the same issue. Reading through the forums, it looks like the solution has been listing partially in lots of places. Can you walk me through the steps to fix it -from the beginning? I assume you must have the CLI interface to update the keys? I am pretty new and was messing around with an auto off switch, and I caused the “brown-out” conditions that appear to be related to this failure.

Thanks

THANKYOU!!! My one and only photon and I thought I already ruined it in just a few days.

I'm running a course with the Photon at my University and a student brought a Photon to me with this problem (rapid cyan, red/orange, cyan). After basic debug, I found this thread and tried a few things listed here. These are the results:
1.) Copy cloud keys from Photon to computer for future reference:

dfu-util -d 2b04:d006 -a 1 -s 2082:512 -U cloud_public_from_orserphoton3.der

2.) Update keys from cloud (https://s3.amazonaws.com/spark-website/cloud_public.der)

dfu-util -d 2b04:d006 -a 1 -s 2082 -D cloud_public.der

2b.) Reboot photon, no luck (still blue/red/blue), back into DFU mode

3.) Generate fresh keys works fine

particle keys new photon

4.) Try to load keys into Photon

particle keys load photon.der

Now here is where things get interesting, I get the following error message:

x-10-104-114-249:keys_debug_001 davidj$ particle keys load photon --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_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: /bin/sh -c openssl rsa -in pre_photon.der -inform DER -pubout  -out pre_photon.pub.pem
unable to load Private Key
140735139844944:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157:
***<snip>***
140735139844944:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:Field=pkeyalg, Type=PKCS8_PRIV_KEY_INFO

Error saving key to device... Error: Command failed: /bin/sh -c openssl rsa -in pre_photon.der -inform DER -pubout  -out pre_photon.pub.pem
unable to load Private Key
140735139844944:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157:
***<snip>***
140735139844944:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:Field=pkeyalg, Type=PKCS8_PRIV_KEY_INFO

(I've snipped some of the error message, let me know if you'd like to see all of it.)
Now even though I'm doing a "particle keys load" command Particle is downloading the keys from my photon and doing something with openSSL? I'm a little hesitant to try @mdma's original command:

Since it appears you've changed this method slightly in the latest release of the CLI tools.

I'm running OSX with the openssl and dfu-util installed; here are my version numbers as https://docs.particle.io/guide/tools-and-features/cli/#advanced-install doesn't state a particular version requirement.

x-10-104-114-249:keys_debug_001 davidj$ openssl 
OpenSSL> version
OpenSSL 1.0.2a 19 Mar 2015
OpenSSL> quit
x-10-104-114-249:keys_debug_001 davidj$ dfu-util --version
dfu-util 0.8

Any suggestions would be appreciated.