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.
Thanks
// 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...");
}
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.
Additionally
How are you compiling your code?
What system version have you got on your Electron?
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 dfu-util@lists.gnumonks.org
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!
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 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:
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
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 project.properties 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.
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.
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.
