Serial.println not working on Electron


I’m trying to get the simple code below to work on an electron. Flashing over serial works, but when I try monitoring it just hangs there doing nothing, although it shows as connected. Using putty does the same thing.

The code, however, works perfectly in my photon. So I assume it should work in the electron too.

I’ve spent many hours trying to get this working, so I can have some debugging info on my screen. Any help would be much appreciated. I feel like using a sledge hammer on it!!

I’m using Windows 10 and the ‘offender’ is an Electron with 0.6.0 firmware version.


 // setup() runs once, when the device is first turned on.
void setup() {
  // Put initialization like pinMode and begin functions here.
  Serial.begin(9600); //or USBSerial1.begin();
  Serial.println("Hello World!");

// loop() runs over and over again, as quickly as it can execute.
void loop() {
  // The core of your code will likely live here.
  Serial.println("Hello again...");

Do you really want to print “Hello again…” every millisecond?

Have you checked in Device Manager whether your Electron is seen as COM port?
Are you using the correct port number?

I don’t care about printing every millisecond. It’s just a test to see it actually prints something.
I am using the correct port. As I said it does connect to the port and I can flash --serial, only it doesn’t print anything. The same code works on the photon just fine. I have them both connected at the moment and one works one doesn’t.

I’d add some delay(1000) to loop() and instead of particle flash --serial I’d suggest you use particle flash --usb (in DFU Mode/blinking yellow) as --serial may even report success when the upload fails.

You could also add some other D7 blink code to have some extra means of telling whether your new code actually stuck.


  • How are you compiling your code?
  • What system version have you got on your Electron?
  • Which system version are you targeting?
  • What does particle list return for that device?
  • What does particle identify say?

These would be valuable infos to state in the OP.

Done that too… same result. I did not bother with the delay as this is just a simple test. I want to print to the serial what I would send over the GSM connection (to save data while debugging). Since the actual program wasn’t printing anything I wrote this very simple test to see if it works. It doesn’t.
Looking at the topics here, I’m not the only one with this problem.

PS C:\Work\electron\serial> particle flash --usb se.bin
Found DFU device 2b04:d00a
spawning dfu-util -d 2b04:d00a -a 0 -i 0 -s 0x08080000:leave -D se.bin
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 2b04:d00a
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08080000, size = 4420
Download        [=========================] 100%         4420 bytes
Download done.
File downloaded successfully
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!

Flash success!

Is the Electron breathing cyan?

For me Serial.print() works just fine - with all my Electrons :wink:

Well, your choice to ignore suggestions …

This code

void setup() {
  Serial.println("Hello World!");
  pinMode(D7, OUTPUT);

void loop() {
  Serial.println("Hello again...");
  digitalWrite(D7, !digitalRead(D7));

renders this output (along with a D7 blink)

PS C:\Users\andyr> particle serial monitor --follow
Polling for available serial device...
Opening serial monitor for com port: "COM3"
Serial monitor opened successfully:
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...
Hello again...

Yes the electron does blink cyan, slowly. The same like the photon next to it. One works, one doesn’t.
I ignored the suggestion because:

  1. I had the delay before and the result was the same
  2. The photon works w/o delay
  3. It shouldn’t matter if there’s a delay, or not.

It shouldn’t but for some Windows users it did due to some driver issues (e.g. wild mouse movement)
Reducing all possible side-issues is one common debugging strategy.

I have tried your code on both devices. The result is the same. The photon works, the electron doesn’t. So the delay doesn’t make a difference.

Maybe I’ll try on my linux laptop later… I was suspecting the windows drivers too.

How about the other questions

Is the D7 LED blinking on the Electron?

I compile with “particle compile electron” in a command prompt in the project folder.
The firmware is 0.6.0

PS C:\Work\electron\serial> particle list
Fireblade [34002d000b51343334363138] (Electron) is online
LG [36001c000b47343138333038] (Photon) is online

PS C:\Work\electron\serial> particle identify
? Which device did you mean? COM4 - Electron
(node:9572) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Writing to COM port (GetOverlappedResult): Operation aborted
(node:9572) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

D7 not blinking. It does only on the photon.

PS C:\Work\electron\serial> particle serial monitor
Opening serial monitor for com port: "COM4"
Serial monitor opened successfully:

What version CLI are you compiling with?

If your Electron has 0.6.0 and you have one of the more recent CLIs you may want to use

particle compile electron . --target 0.6.0 --saveTo e060.bin
particle binary inspect e060.bin
mode COM4 14400
particle flash --usb e060.bin

to make sure you are targeting the correct system and flash the correct binary.
The missing D7 blink suggests that the code is either not sticking or you are flashing the wrong binary.

Your binary inspect output should look like this

PS C:\Particle\Test\SMSTest> particle binary inspect .\e060.bin
 CRC is ok (1765942c)
 Compiled for electron
 This is an application module number 1 at version 4
 It depends on a system module number 2 at version 102

Are you building a full project with a file or just a single file project?

Also unplug the Photon from USB while doing any of this.
The which ? Which device did you mean? message suggest some kind of port collision.

1 Like

YES!! Targeting worked! Thank you very much! I’m new to this and would’ve taken me a loooong time to figure it out on my own. Many thanks!

1 Like

You’re welcome!
Good to know you can move on from here.

BTW, I’d still suggest you update your Electron (and Photon) to 0.6.4 (and 0.7.0 as soon as released).
If you wish you can already go with 0.7.0-rc.6 which seems quite stable already.

Thank you! I will upgrade the firmware.
The project is to attach this asset tracker kit to my motorbike.

Will it be safe to power it externally to the bike’s electrical system? It puts out a max 14V when the engine is working.

I’d add some filtering to the supply.
Especially during/after cranking you might get harmful spikes that exceed the 14V by far.
This link talks about cars but in priciple this goes for motor bikes too.

I have an electronic voltmeter installed on the bike (I had the stator fail on a bike before and it drained the battery w/o any warning. Ever since I install digital voltmeters to keep an eye on the charging system). I haven’t seen it go over 14V, It goes to about 9 when cranking. I’m a mechanical engineer, so my knowledge of electronics is limited, but I’d assume this simple voltmeter wouldn’t show very fast spikes, so I’ll look into the filtering as soon as I get the software done.
Thanks again for your help!

As you guessed the electric and mechanic inerta of a “standard” voltmeter is too high to show these spikes (and good so when you want a steady reading) but even very short voltage spikes can damage your precious electronics.