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 System.enterSafeMode(); System.dfu();
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:
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
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
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
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?