There are several posts on here on how to solve the Electron’s fast cyan blinking, but what is the real cause? This has affected me twice in 2 days running 0.7.0, and the only solution has been to run:
particle keys doctor
I am worried this will happen when deployed. What is the real cause of this? I have a feeling it’s related to moving in and our of cellular areas with no coverage to full coverage or vice versa.
Thanks in advance!
I don’t know the root cause for your scenario but since particle keys doctor seems to resolve your issue, perhaps take a look at the DeviceKeyHelperRK library by @rickkas7 . It’s meant to store the device key in non-volatile storage of your choosing, monitor the device key for errors and restore the good copy if there’s an issue.
thanks for the suggestion. i was not aware of this library and i will investigate.
There are several causes of this, not all of which are keys.
Is it stuck on fast blinking cyan forever, or are there red or orange blinks?
Does the reset button alone allow reconnection to work?
Does the problem go away if you completely unplug the power (USB and battery)?
Usually, fast cyan forever, but one time I saw a red very briefly.
No, the reset button does not work. Multiple reset attempts also dont work.
No, unplugging the power/USB or battery does not help.
Thanks for the response.
In that case, it does sound like it could be a keys issue. Make sure you do not let your Electron go to an empty battery. Ideally, when the SoC on the battery falls below 20%, do not turn on the cellular modem and go back to sleep until you have sufficient power.
could you elaborate on the “keys issue”? I dont understand what this means, or what particle doctor is doing to fix it.
The lost keys, lost settings, and lost boot loader may be variations of this problem:
In some situations, it tends to be a low-power brown-out type of situation that occurs. It appears that certain flash sectors can be erased. Sometimes, it's the sector that contains settings (like Wi-Fi settings or device keys), and sometimes it's the boot loader.
When the boot loader gets erased, the only thing that happens is the blue D7 LED will light dimly, and it will not respond to other buttons. When this happens, we typically replace the device, though users can typically fix it with JTAG/SWD programmer.
This has a tendency to occur on Electrons mainly because more of them operate on battery power. It can also occur on Photons. It has also been seen on a RedBear Duo, which we don't even manufacture. All of these devices have similar STM32F205 processors, however. It also is not specific to battery power, it can happen when using a power adapter as well, though much less frequently.
Also, it's not simply running at a low voltage. The processor has protection for that, and we've tried running the devices at all voltage levels and can't make the problem happen. It appears to be some combination of factors that is quite elusive.
For battery powered devices, the best workaround until the problem is solved is to make sure you don't run until the power goes completely out. Instead, use sleep modes to conserve power until sufficient power is available again. I recommend running with SYSTEM_MODE(SEMI_AUTOMATIC) and checking the battery SoC at boot or after waking from sleep. If it's below 15 to 20% SOC, immediately go back to sleep and do not turn on the modem.
We've added code to system firmware 0.7.0 to be able to recover the server key automatically if this occurs, as well, though this may not work in all cases.
For automatically restoring your device private keys, this library can be used:
Also 0.8.0-rc.x has several updates to address corruption of DCD/DCT for Electron/Photon/P1 (which can affect device/server keys and wifi credentials), and the latest 0.8.0-rc.11 has addressed the no-boot issue with this change:
I can vouch for Rickkas’ DeviceKeyHelper library. I have 60 deployed Electrons and was experiencing the same issue. After using this library, the occurrence of the issue significantly decreased. (although it still does happen sometimes)
Very useful information. Thank you! My problem is not related to low voltage/low battery, but I was wondering if a newer firmware should be tried. Something like the DCD/DCT corruption [ch17416] sounds like it’s closer to the actual issue.
What does it mean if the problem goes away with a power reset?
If the problem goes away by removing power, then either the device or modem were in an unhappy state. There are a few techniques here that can help with that: