Electron Mode Button


@nrobinson2000 yea still not working for me, I had selected release/stable and po baud rate before. I just re-did it with po config as you suggested, and I actually explicitly entered 19200 for the baud rate rather than po. No dice… I’m going to restart into Windows and try there.


If you want to try a baud rate other than 19200, just edit the ~/.po config file.


drats, foiled again… po-util has nothing to do with windows, so that’s not going to help me. However, in Windows, sure enough, if I type mode COM10 14400 into a command shell, I get a blinking yellow RGB LED…


Is that with the system firmware compiled with po-util?


@ScruffR What’s the difference between blinking yellow and blinking blue RGB state as far as particle-cli is concerned? Can I execute particle flash --serial firmware.bin from a blinking yellow state (even though the prompt says I need to be in a blinking blue state)?


To change the baud rate po-util just modifies:

And changes the START_DFU_FLASHER_SERIAL_SPEED=14400 line to:


It then compiles both system firmware parts and flashes them.


Nope, blinking yellow is DFU mode and blinking blue Listening Mode.
But for flashing firmware via USB, I’d always recommend using DFU Mode in conjunction with particle flash --usb firmware.bin


@vicatcu I think I just found the problem. The electron actually now has three firmware parts and not two. Currently po-util only builds the first two. I am working on a fix for this.

I just pushed the fix. Update po-util and try it.


@nrobinson2000 sweet, I’ll hope back over to Ubuntu and give it another go.


I see, the --usb flag vs. --serial was the missing link there for me, thanks.


Once you’re in DFU mode by this mechanism, is there any way to get out of it short of a power cycle or push of the reset button?


OK, it works now, well done! I just did:

$ po update
Updating firmware...
No local changes to save
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 12 (delta 2), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (12/12), done.
From https://github.com/spark/firmware
   2ca1473..04f35df  develop    -> origin/develop
 * [new branch]      release/v0.6.1-rc.1 -> origin/release/v0.6.1-rc.1
 * [new tag]         v0.6.1-rc.1 -> v0.6.1-rc.1
Already up-to-date.
Updating particle-cli...
Updating po-util..

… then re-ran po electron upgrade, and now po dfu-open gets me into DFU mode (blinking yellow).


That’s great to hear!

po dfu-close

Gets the device out of dfu mode by writing /dev/null, “nothing” to the device over dfu-util, which makes the device reboot.


New discovery, I load the electron with this shell script I whipped up:

rm *.bin
particle compile electron . && \
x=`ls *.bin` && \
/home/vic/po-util.sh dfu-open && \
sleep 1
particle flash --usb $x
/home/vic/po-util.sh dfu-close

The sleep seems necessary, must be some kind of race condition in dfu-open. The last line is not really necessary, but it’s the last thing I tried. The problem I’m encountering is that if I execute that script in my firmware directory, and then afterwards open a terminal to the electron at 115200 (notably not the magic baud rate), the electron goes into DFU mode. :confused:

I tried adding some sleep between the flash and the dfu-close but that doesn’t seem to have any affect. If I do dfu-close after failing to connect at 115200 (e.g. using miniterm, inexplicably inducing DFU mode), the next time I try to connect at 115200 it works fine (doesn’t go into DFU mode).


This is a known issue with serial ports on Linux, and is reported here https://github.com/nrobinson2000/po-util/issues/7

To quote @jvanier:

I get this behavior on Linux as well. The short of it is that Linux remembers the last baud rate and it first opens the port with the old rate, then changes the baud rate in a 2nd operation.

At this point I don’t have a good solution other than moving away from the “magic baud rate as a control message” which is what we’ll be doing in a future firmware.



I am trying to use mode comx14440 on windows to put the device in DFU mode but it is not working.

It returns following and not entering into DFU mode.
Default to 7 data bits
Default to even parity

Status for device com7:
Baud: 14440
Partiy: Even
Data Bits: 7
Stop Bits: 1
Timeout: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: ON
RTS circuit: ON


maybe using the correct baudrate might make a difference?


I tried different baud rate but it is not working.

I have found following on Serial Tutorial

Changing operating modes with USB Serial
Normally you press buttons to enter listening or DFU mode on the Photon or Electron. You can also trigger it by making a USB Serial connection at a specific baud rate.
For example, on the Mac you can use this command to enter DFU mode:

stty -f /dev/cu.usbmodemFD1141 14400
(The device name, cu.usbmodemFD1141 in this example, may be different on your computer.)
The special baud rates are:
14400 DFU mode (blinking yellow)
28800 Listening mode (blinking dark blue)

But I am not sure why these modes are not working. I tried for Listening mode also but it is not working.



Sorry. It got working. The baud rate changed to 14400. It is working now. Thanks.