Electron stopped working?

Till Brett has got time, this is what I found

to dump out what the current state of your device is.

And here should be your way to resurrect your device


cc @BDub

update, I downloaded the 0.6.1 (3 parts) firmware files and tried to upload them using the ST-LINKV2 using
st-flash write ~/Downloads/system-part1-0.6.1-electron.bin 0x8060000
as command and got:

st-flash 1.3.1
2017-04-20T17:00:46 INFO src/common.c: Loading device parameters…
2017-04-20T17:00:46 INFO src/common.c: Device connected is: F2 device, id 0x201f6411
2017-04-20T17:00:46 INFO src/common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0x800000 bytes (8192 KiB) in pages of 131072 bytes
2017-04-20T17:00:46 INFO src/common.c: Attempting to write 52620 (0xcd8c) bytes to stm32 address: 134610944 (0x8060000)
Flash page at addr: 0x08060000 erased
2017-04-20T17:00:46 INFO src/common.c: Finished erasing 1 pages of 131072 (0x20000) bytes
2017-04-20T17:00:46 INFO src/common.c: Starting Flash write for F2/F4/L4
2017-04-20T17:00:46 INFO src/flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 19852
2017-04-20T17:00:47 INFO src/common.c: Starting verification of write complete
2017-04-20T17:00:47 ERROR src/common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

as error.

Hmm, yeah I’ve seen that error before on Mac and I usually switch to Windows and use the ST-Link Utility when that happens. Do you have that option?

nope, at least not the next week. Leaving for Vienna in 7 hours where I hope to demo those drifters but from the 3 I have with me, 2 are bricked. Did bring ST-link this time though.

This afternoon while testing my Electron, my USB serial print to screen stopped working. I looked at the device and the 3 colored LED in the center is OFF and the D7 led is dimmly lit. Tried putting it into Safe Mode using the switches but nothing happens, center led remains Off. In the Terminal app on OSX cd /dev and type ls, tty.usbmodem1431 no longer shows up. From reading these posts it sounds like my boot loader has been erased. My Electron had been powered over USB, no battery.
Please advice on how to proceed
Thank you.

Just started the Norwegian Blue fix, after answering (y) to the last question the Photon Programmer LED turned Orange but there has been no been no response back on the Terminal window. Its been 10 minutes in this state. Target Electron Led is still Off, no activity. I pasted my terminal window below. I used CLI to download latest 0.1.4 of Norwegin.bin
Any ideas? Do I need to disconnect USB cable and try again?

Bootloader fixerupper, v0.0
This utility fixes up the bootloader on another device.
Before running this, be sure you have correctly wired the programmer and target devices.

WARNING: Do not use this with a target device that is showing LED activity.
LED activity on the target device means the bootloader is functioning and any problems with
the device can be fixed using particle-cli.

WARNING^2: Please read the message above!

Do you have a dead device and wish to continue? [y,N]:y
Not sure about that.
Do you have a dead device and wish to continue? [y,N]:y

Disconnected the Photon after 2 hours , photon still in the state descibed above. Removed all jumpers and reconnected the USB. Now the center tricolor LED is Solid Blue. I search for this condition and found this thread, Cannot claim Photon - SOLVED

Following the steps outlined in this thread, I did the following
In DFU Mode
dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D system-part1-0.6.2-photon.bin then, dfu-util -d 2b04:d006 -a 0 -s 0x8060000:leave -D system-part2-0.6.2-photon.bin
particle keys new then, dfu-util -d 2b04:d006 -a 1 -s 34 -D device.der

Led blinks and changes colors but returns to steady blue. I cant get into Safe Mode, when I release the Reset switch while holding down the Setup switch when the led turns blinking magenta, it immediately goes to blinking Green. It will still go into DFU mode.
Any ideas on what to try next?

For the Electron you may need to consider this statement from the datasheets


1 Like

I guess that explains why it behaved that way when running Norwegian blue. Should I connect the 3.3v from the Photon, to Vbatt on the Electron to power it up when running Norwegian blue?
Thanks so much for pointing my error out. Have a great day.

Try attaching the Li-Po battery.

3 days ago my Electron developed the same problem, dim D7 Led, multicolor LED OFF. Tried usb Norwegian Blue fix and I was unsuccessful. Now I seemed to have lost my Photon as it will . no longer connect to the internet. I was running 0.6.2 when it lost the bootloader. I order a ST-Link V2 Programming Unit mini STM8 STM32 Emulator Downloader M89 Top ST JTAG tool.
Would you please point me to the procedure and bootloader file for using the JTAG tool.
Thanks so much.

@ovro67 would you please contact https://support.particle.io for help on restoring your Photon and Electron back to a factory state?

Also, it sounds like you said your Electron was initially connected to USB for Serial prints, and your LiPo battery disconnected? Please be advised that most USB ports cannot handle the up to peak 2A currents that the modem requires, and will cause a brown out at the electron. To remedy this, you should keep the LiPo battery attached. Do you remember what steps took place between the time things were functioning and not? Were you reprogramming anything (dfu/ota/y-modem), and what kinds of power/flash functions were you using if any (sleep/eeprom/etc…)?

1 Like

Hi there

I have an electron in the field that stops working with no RGB led and a dimly lit Blue D7 LED, HOWEVER a reset is bringing this back to life at the moment.

Relevant Info.

  1. I have 2 of these devices running the same code and only one of them is doing this.
  2. There is no Lipo battery attached we are supplying the device from our own carrier board via VIN at 5V and 2A.
    3, The power supply is very steady (120Ahr @ 12V) External Solar Regulator charging the batteries.
  3. I’m using 0.7.0-rc.3 firmware
  4. Sometimes it runs for 2 weeks, yesterday it ran for 7 hours.

I have a few questions.
1, If this is a user code fault, shouldn’t it blink the RGB red with the SOS, or white, or some colour, or anything other than off?
2. Has anyone seen this fault (no RGB LED, and dim D7 - recovered by a reset)
3. I have the application WDT running and it’s not resetting the device.
4. Has anyone got a nice function to see processor utilisation?
5. What does the Electron do with USB Serial printf if the USB is not connected? does it skip the section of code or still go through the process of printing it? - I wonder if I have too much serial debug slowing it down in some wierd way.

Thanks and Regards


@marshall, the “no RGB LED and dim D7 LED” is the classic indicator for a low voltage condition leading to a wiping of parts of the flash, typically the DCT area. The 0.7.0-rc.3 system firmware includes an auto-healer for this so this is why hitting reset brings it back to life.

The thing with the onboard LiPo is that it can supply high peak current for the modem. This means fast response (ie rise time) to current demand. You need to make sure your 5v regulator can supply (at least) 2 amps of current with a fast rise time. You should over-spec the regulator so it doesn’t get hot and runs well within its operating range. What regulator are your using?

The best thing you can do is setup logging on the device to get a detailed output of the system activities.

The print occurs as if the port was connected but it doesn’t go anywhere. You could qualify your prints with isConnected() so that you skip the print when a host is not connected.


Thanks for the fast reply.

Our regulator is a Active Semi ACT4060A we chose this as we are able to put a 12V Solar panel directly on it without it blowing up. the O/C voltage of a solar panel approaches 22V. (anyway we don’t use a solar panel directly in this case)

I had a quick look at the datasheet but didn’t see any demand curves vs rise time on them. I’ll put a battery on and see if that results in any improvements, its a really easy fix.

I’ll report back on the results.

I like the idea about the isConnected() function you mentioned. I have my debug out already in a function so it’s easy to add in just the one spot.
here is my debug function if anyone else wants it, it prints the line number and the function name as a prefix, then nicely aligns the message.
It takes standard printf arguments (or no arguments) so it is easy to replace existing Serial.printlnf etc with it.

#define TRACE_PORT Serial
#define OPITO_DEBUG(fmt, ...) WITH_LOCK(Serial) TRACE_PORT.printlnf("%-4d:%-30s> " fmt, __LINE__, __func__, ##__VA_ARGS__);

here’s how to use it.

OPITO_DEBUG("callback rx-d %s", str);


hi bko i have same condition one of electron as you stated
what post should i follow

followed this with no luck

get same error

SWD Fault error
Please double check the wiring, then try again.
Do you have a dead device and wish to continue? [y,N]:

@viraj what is the symptom of the electron? Are the LEDs lighting up?

Do you have a dead device and wish to continue? [y,N]: after pressing on y the target electron D7 led lights solid blue, which was previously dim blue
and same error prints on hyperterminal
SWD Fault error

What happens when you attach the Lipo battery? Can you take a photo?

when you attach the Lipo battery?

–> it remains same solid blue no RGB led lights