Electron Mode Button


I’ve got a few Electrons that I’m prototyping a product with. I want to embed these in an enclosure and still be able to program them over USB. It’s no big deal for me to expose a panel mount USB port to serve this purpose (along with to allow battery charging). But thinking through it, I’m also going to have to expose some way to bring out the RESET and MODE buttons to be panel mounted. The Electron has the RST pin on its headers, but looking at the Eagle files, it seems like the MODE button signal doesn’t make it off the board. I just thought I’d ask here on the off chance that someone has encountered this “problem” before, and to see if there are any creative solutions people have come up with


I’m not sure if this actually is what I assume it is, but if you look at the bottom of you Electron, you’ll see a solder pad near the SIM socket with a silk print MODE near it.
Maybe this could help.

If you just want to provide a way to put your device into Safe, DFU or Listening Mode, you could do that via a normal GPIO and some of the System commands too.


@ScruffR Thanks yea I see that now in Eagle too (it’s routed on an internal layer), but I’d need to solder a wire to that pad to gain access to it, which isn’t the end of the world. In order to program over USB you have to hold the Mode button down for three seconds. Perhaps I’ve missed a programmatic alternative to getting into that state, but that’s what the CLI prompts you to do before attempting a USB firmware load (get the RGB LED blinking blue).


If you intend to use USB anyway you can always use the magic baud rate 14400 for the serial port to force the device into DFU Mode

On Windows you’d just use mode COMx 14400 where COMx stands for the serial port Windows assigend to your device.

Programattic ways are

  WiFi.listen(); // for WiFi devices


Man, I learn something new everyday :)… i’ll give this a try, does it work differently in Linux (where can I read more about this feature)?


Linux might pose some problem there as 14400 is not a standard baud rate you can easily select

I think @nrobinson2000 addresses that by changing that to 19200 in this thread
Po-util: a Toolchain Installer / Helper for Linux and OSX


po-util is a utility I created for Linux and macOS that makes the local Particle experience much better.

One of its features is changing the magic baud rate the Electron will respond to by recompilling the system firmware.

You can do this with po-util by doing:

po electron upgrade

Whenever po-util needs to put a device into DFU mode, it actually runs:

stty -F /dev/ttyACM0 19200

You manually put an Electron into DFU mode by doing:

po dfu-open

Whenever you build and flash firmware if automatically puts the Electron into DFU mode and flashes it with dfu-util:

po electron flash

If you have any questions about po-util please don’t hesitate to ask them here.


@nrobinson2000 cool and thanks for chiming in! I’m excited to try it out.


@nrobinson2000 So I installed po using the shell script, created a project with po, put the electron into dfu mode using the button, did po electron upgrade successfully… what’s supposed to happen now when I do po dfu-open? It just completes silently and I don’t see any difference on the device (e.g. RGB)…


The Electron should be in DFU mode, flashing yellow.

What if you unplug the electron and plug it back in?

stty -F /dev/ttyACM0 19200

Is essentially what po dfu-open does, where /dev/ttyACM0 is automatically determined from the available serial devices connect to your computer.

Do you have multiple Particle devices plugged in? If you do, the wrong serial port could be picked up.

po-util finds the serial port by doing these commands:

ls -1 /dev/* | grep "ttyACM" | tail -1

What distro are you using?

  • I’m on Ubuntu 16.04
  • particle --version => 1.18.0
  • Only one electron plugged into my computer
  • ls /dev/ttyA* -> one hit: /dev/ttyACM0
    • same result from ls -1 /dev/* | grep “ttyACM” | tail -1
  • stty -F /dev/ttyACM0 19200 => RGB LED just keeps breathing white
    • same result from po dfu-open


Weird. It should be working.

And you are sure that you recompiled and flashed the system firmware? Did dfu-util upload both parts?

Have you rebooted after installing po? It adds you to the plugdev group which is necessary for you access serial ports without requiring sudo.

Before you reboot try:

sudo stty -F /dev/ttyACM0 19200

If that doesn’t work, reboot and it will hopefully work.

If it still doesn’t work, try recompiling and flashing the system firmware, and then build your project locally and flash it.


@nrobinson2000 here’s a gist of the entire oiutput of running po electron upgrade, seemed to complete without any anomalies to me.


Hey folks! Also worth noting that as of v061 (which is about to be in prerelease), you will be able to mirror out the LED and buttons to a compatible GPIO that you choose. Check out the following link – first note in the changelog!


@will Great! Good to know I’m not that far out of the box in my thinking :slight_smile:


@vicatcu Is po dfu-open still not working?

It could be not working because you accidentally chose the default baud rate to trigger DFU mode. To fix this, just do po config, choose release/stable as your branch, and choose po as your baud rate


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