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

Troubleshooting
81

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
82

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

83

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

84

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

85

:stuck_out_tongue_closed_eyes:
Ah these users. They keep wanting twice what you giveā€¦ :weary:

1 Like
86

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
87

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
89

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

90

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

91

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.

92

@Phoenix,

I wonder if the newer version is causing issues. mine is OpenSSL 0.9.8zg 14 July 2015 on a Mac V10.11

93

Not a clue why I have a different version than you do (OSX 10.10.5). It is however maintained by apple and Homebrew specifically warns against installing a different version. A quick search of vulnerabilities shows 1.0.2a as being sufficiently up to date.

The more I stare at this the more I think ā€œkey doctorā€ is just downloading the old private key off the Photon, then trying to generate the public key from the private key. Obviously if the old private key is corrupt it has a good chance of failing.

Should I try just over writing the private key with @mdmaā€™s command above? Again, Iā€™m just looking for a little advice as Iā€™m not particularly comfortable with DFU mode and dumping binary data into random chunks of memory in the Photon.

94

At the end of the day, I decided to bite the bullet and DFUā€™d a new private key to my photon:

dfu-util -d 2b04:d006 -a 1 -s 34 -D 4400snip3738_new.der

This recovered my photon.

I think this clearly points to a bug in the current version of particle-cli (where ā€œparticle keys load photon.derā€ is unable to handle corrupt private keys.) I did save my private key, cloud key, and another misc DFU dump; should anyone care to try and replicate this bug.

95

excellent! Iā€™d be very interested in seeing the corrupted private key. Could you let me have them via a PM? (you can rename them to .gif and upload as an image.)

96

@mdma, @bryce, I have two Electrons that are totally unusable! Any progress on fixing this? I tried making a new Electron firmware image (monolithic) from the latest develop repo and flashing over then copying the server key over but still no luck. It would be great to have a fix-it guide. :wink:

1 Like
97

@Phoenix confirmed there is a bug here. It tries to backup the existing key, and then generate the public key from it. In the corrupt key case, it fails. It should continue on regardless. I will file an issue for this and get it fixed.

98

Glad I could help, thank you for following up on this.

99

One of my Photons exhibited the quick red burst behavior 2 days ago for the 1st time. After scouring the forums for possible fixes, the solution that worked for me was the following:
Get particle cli, node.js, openssl, zadig, etc. installed on my windows 8 machine as outlined by @HappyCookie

Plus, making sure that I had properly added the pathing instructions for openssl and the dfu utility to my user variables pathing list. This was actually the tricky part for me. I had accidentally placed commas after each entry instead of semicolons :stuck_out_tongue_closed_eyes:
Running command prompt as admin, I then entered ā€œparticle keys doctor (my device id)ā€ while having my Photon in DFU mode. This repaired the Photons public key, which had most likely corrupted while I was doing some funny things with voltage on a breadboard.
I must admit this took me a long time to figure out. Thank you to everyone in this post and others that helped diagnose this issue :wink:

101

Hi @kennethlimcp ā€¦ i have this same problem with one of my new photons ā€¦ when i floow your four steps, everything looks fine, excepting step 4, since i obtain the following message when i run it:
ā€œPlease provide a filename for your deviceā€™s public key ending in .pub.pemā€ ā€¦ but file exists and I am in the current directory where the file is. whch could be the problem? ā€¦ in case i successfully run this last step, shoud the photon to finally connect to thw wifi after reseting it? ā€¦ once again, thanks for your help and support!!!

102

So the brownout issueā€¦ Is it a bug? Or is this expected?

If itā€™s expected the battery/power shields need to be modified to prevent this from happeningā€¦

Can anyone from Particle comment on this?