[RESOLVED] Electron lost program / corrupted (and in infinite bootloop - flashing green then white) after power loss

Particle community,

First post but I am having a big problem. :frowning:

I ordered 2 Electron kit from Official store (U260 - AUS/US version). I also purchased a U270 Europe version from my local online store. I am in Australia and we have 3 major carrier - Telstra (U260), Optus and Vodafone (U270 freq). The later two are offering much cheaper data but with limited coverage outside metro area. I used my own SIM to activate and claim the kit as I get greater flexibility and more data every month on those IoT devices.

The first few days I was really impressed with those little kit and it seemed there was no obvious issues while keep it running for days.

However, after I disconnected the power (USB+Battery) from one of the unit, my nightmare began.

Both of the unit have a very high (nearly 100% on my own code - just to flashing the D7 LED) possibility to stuck in bootloop (as far as I believe). It powers itself up but ends up with flashing GREEN, goes WHITE for seconds, then repeat.

Luckily, I figured out to issue the original command during activation stage to bring the device back to work, but I have to say this it not fun…

particle flash --serial firmware.bin

I kept those firmware file I downloaded for each of the device.

I had some read and search and some of the thread I read got a dead-end. Electron unable to connect to Particle Server

I am taking stability seriously so without a practical solution for this, the product seems not suitable for my project / product, yet.

Can anyone point me a direction to avoid this from happening? I am getting quite frustrated and I really wish I could use this kit for some projects.

Would this issue be possible to get solved via a future firmware update?

Thanks in advance! :laughing:


There is not a lot of info we could go on about what might cause this.

Apart from the known but not yet solved issue with “brown-out” conditions and some occasional disconnets due to SIM contact issues on ~1% of devices (blinking blue) the stability is rather good in my experience.

Just a hint

particle flash --usb firmware.bin

is much more reliable when it comes to actually telling you whether a flash succeeded or not.

But as said, we need more info.
How do you exactly power the devices?
Even if it’s simple, how exactly does your code look?
Have you considered SYSTEM_THREAD(ENABLED) and/or a non-AUTOMATIC SYSTEM_MODE()?


@ScruffR, Thanks for your prompt reply.

I am actually using a modified code from the blinking LED program. I put a few more lines to change the duration between the blinking and upload a counter every 2 minutes.

I am powering the device using the USB port and the battery. During the test, I usually unplug the USB cable and then disconnect the battery connector - this will cut down the power completely.
I would think the “brown-out” conditions might be the same issue.

I was thinking the device was faulty but I can replicate the issue by using the different model…

In regard to the SIM connectivity issues, I didn’t get any SIM related blue-light issues from my observations. Also, I am using a 3rd party long life Telstra SIM so I could even eliminate this scenario by calling the number I am currently using on that IoT device.

I must say I cannot afford reprogramming the unit every time my clients get a power failure - I really, really wish this problem can be solved in the near future.

I will definitely have a little bit read for the 2 modes you mentioned above and give it a shot. I am doing this in my spare time so I will keep you updated.

This is the code I am using:

int led1 = D0; // Instead of writing D0 over and over again, we'll write led1
unsigned char countdown = 255;
unsigned int count=0;
int led2 = D7; // Instead of writing D7 over and over again, we'll write led2

void setup() {
  pinMode(led1, OUTPUT);
  pinMode(led2, OUTPUT);


void loop() {
  digitalWrite(led1, HIGH);
  digitalWrite(led2, HIGH);
  digitalWrite(led1, LOW);
  digitalWrite(led2, LOW);
  if (countdown==0){

void upload() {
    if (count%2==0)


When you are using a 3rd party SIM you have to have the APN setting line in your code - and I don’t see it in yours.


STARTUP(cellular_credentials_set(APN, "", "", NULL));

(replace APN with the actual APN string for your provider)

Put it at the top of your project and I’d expect your troubles to be gone

1 Like


Thanks heaps. It’s all up and running now.

It’s kind of the strange issue to me. The config stays if I don’t put any programs on - will a user program erase the APN settings in-built with firmware.bin?

I think I also like the idea to include SYSTEM_THREAD(ENABLED) option so my code would run soon after it powers up.

One more question, would it be possible to read / retrieve ICCID information from the user program? Let’s say I am using 2 carriers for my projects and it would be great if I can write few more lines to do auto setup based on ICCID (first few digits would do I believe)?



Yes, any new firmware will overwrite the previous firmware.

The reason why the setting persists a firmware update is that the APN is written by the code into the cellular modem module and a mere reset does not power down the modem, hence the setting persists. But once you de-power the modem that setting will be gone and your code has to ensure that the modem gets “programmed” correctly again.

Yes that is possible via the respective AT commands of the modem and Cellular.command()
I just don’t know the exact command off the top of my head.

Another way is shown in this thread (hope this still works)
[Electron] retrieve IMEI and ICCID

This tutorial is also worth a ready
Electron 3rd-party SIM tips




I think this question can be marked as resolved for now.

I am now a happy customer :smiley: