I tried 0.6.0 prerelease with an app known to work reliably with current release. Could never get 0.6.0 to connect to serial terminal of Particle IDE. Verified upgrade with Tinker and firmware identification using WEB IDE. Using WINDOWS 10. The downgrade instructions work great and my app connected right away after downgrade. Nothing else changed. USB cable was never moved or disconnected. No reboot of WINDOWS. Serial must work somewhat as the DFU interface worked w/o problems. I’m using the USB cable for my serial interface.
I think the issue is not really that the interface wouldn’t work anymore, but the devices are recognized as new device and hence will be assigned a new COM port number.
At least this is what I experienced and have seen other users reporting too.
Yes the COM number is a bit of a mystery. Under all conditions sometimes the IDE serial terminal displays a COM number and sometimes it doesn’t. It works with it blank or the COM3 that it displays. The Particle compile displays on the CMND screen usually references COM 3. The very first time the IDE terminal screen came up with 0.6.0 it displayed COM4. Nothing changed in my configuration so it has do to with something in 0.6.0,
Windows usually recognizes the same device on the same USB port as one and hence would assign the same COM number. But sometimes plugging the same device into another USB port on the same machine Windows sees it as new device and assigns another COM.
You can change the auto-assigned COM via DevMgr Advanced Settings to be the same no matter where you plug it in tho’.
And 0.6.0 seems to change the device signature slightly so that the device even gets a new number on the same port.
Maybe “reinstalling” the Particle drivers can fix your issue.
But I can assure you with 0.6.0-rc.1 Serial does definetly work under Windows 8.1 32 & 64 bit and Windows 10 32 & 64 bit.
1 Like
I installed the 0.6.0_rc1 firmware on an Electron and when I plugged in the Electron to try to load firmware or to open a serial window for debugging it would cause my computer to crash every time. Kept giving an error about “Bad Pool Device” or something like that.
I was using a MacBook Air running Windows 8 64 bit. It will not run the Windows Firmware Updater either.
I switched to a different Windows 8 machine and it works without any problems without any changes.
I never had USB issues on the MacBook with the Photons or Electrons in the past.
After many many test w/o reloading any drivers or other changes my serial interface over USB between my electron sketches are working reliably again. I know my problems started when I tried to flash one Electron (using the batch file you gave me long ago using DFU) while two electrons had USB connections to my WIN10 host. Somehow this messed up something and I can’t afford to go down that path again. So I need some help with reflashing (my sketches are working great and reliably using particle function and variable (long string lists)).
I have a two Electron app that communicate via publish variable (1 for each Electron) and MIT inventor mobile app. (one controls a pump and the other monitors a tank).
To test (monitor serial debug data) I use the serial monitor on the Particle IDE (not WEB IDE). The two windows are working one with one connected to COM3 and the other to COM6 (occasionally COM7???)
My updates(reflash) are painful because I have ensure that only one USB is connected.
GITHUB has a very through Particle manual; but, I don’t find an example that shows me how to flash one Electron when two are connected. Both my electrons run the same sketch. So, I can live with reflashing both simultaneously. How do I do this (one selectively or both)? (I know I could fool around, but after two days w/o serial interface I’m too scared).
I just noticed the COM7 appears after unplugging and replugging a USB cable to reflash even though I do a serial monitor disconnect. WIN10 must think COM6 is still assigned. Not a problem just info in case someone is worried about it.
This can happen when the connection is still open while your device resets. Windows will not close that connection but assign a new port to a device that requests a still active port.
Can you remind me of that particular batch file?
If you have multiple devices connected simultaniously (each with its own COM port), you could go with DFU flashing instead of serial.
If you just add a mode COMx 14400 (COMx is the port for the device to flash), that will switch only that one device into DFU Mode and a subsequent particle flash --usb firmware.bin will only flash that one device that is in DFU Mode (blinking yellow).
1 Like
thanks loads for the help. I can struggle through; but, much of this is to help the poor novice. I just noticed that the WIN10 Device manger shows only COM3 even though I’ve been working with COM7 all day. That ought to cause some confusion.
Here’s the bat file. I’m going to update line 2 per my understanding of your suggestion.
I’m a little confused probably because I don’t understand DFU flashing vs. serial with regard to ports. Our bat file seems to have elements of both. Plus it does flash the Electron on COM7 even though or because its
`particle flash --usb firmware.bin```
`REM enter DFU mode
mode COM3 BAUD=14400
REM remove old binary
del *.bin
REM build project in current directory . for Electron and save as firmware.bin
cmd /c "particle compile electron . --saveTo firmware.bin"
REM flash just build binary to device via DFU USB
cmd /c “particle flash --usb firmware.bin”
I see, that’s rather surprising.
Obviously I did already include that baudrate trick back then, and as such you can keep it as is, just replace COM3 for whatever other COMx you’re targeting.
You could even insert a batch parameter there (e.g. mode %1 BAUD=14400) and call the batch like this yourBatchFile COM3
Could you have a look whether you can see COM7 with this (in cmd) wmic path Win32_SerialPort?
And then try if only the “correct” device goes into blinking yellow when you do execute either mode COM3 14400 or mode COM7 14400.
If only one goes yellow, than only that one should actually get reflashed - anything else would really surprise me.
Ok lets back up to your previous suggestion. I was happily monitoring serial data using serial monitor and USB cable on one Electron on COM7,
I followed your suggestion to flash the second Electron with mode COM3 … It flashed but I couldn’t connect using serial monitor. I disconnect and reconnected its USB cable getting the reassuring bell sounds from WIN10. After a bit the serial monitor gave me a COM6 choice which worked great. This seems unduly confusing for the typical user.
On to your last suggestion and with the system running as described above COM6 and 7 I typed
`cmd c/ wmic path Win32_SerialPort?```
and got NODE - PCVIOS the name of my WIN10 system - nothing else.
mode COM6 and mode COM7 showed DEVICE unavailable (I had previously clicked on disconnect in serial monitor). BUT COM3 did put the COM7 electron in DFU. Very confusing. I have no idea what to type for the COM6 electron. If I have to guess at stuff, the system is broken from my POV. Thanks. I should remind you that I’m on 0.5.2 as I attributed all this mess mistakenly to 0.6.0.
In reviewing my reply, I noticed that it shows that COM3 flashed the COM 6 electron and later put the COM7 electron in DFU. Is a quantum system? That’s intended as humor not sarcasm . I’m really impressed with your patience and help.
UPDATE: The device manager shows COM6 so I did mode COM6 and it put it in DFU. I did the serial monitor disconnect first.
I can live with this but something isn’t right.
It might sound like an easy cop-out, but this looks to me like a Win10 problem (are you using 32 or 64 bit, Pro or not?).
I haven’t been able to replicate that issue on my machines (when not deliberately keeping ports occupied).
I’ve got to try the wmic command on Win10, I only tested it on 8.1 yet.
Can you try to explicitly assign COM ports to each individual device via DevMgr an see if the problem goes away this way?
Since I’ve always done that (just for pedantry 
) I seem to be unable to get any “wrong” port assignments anymore (with connection open or not).
I’m somewhat satisfied. I can control the flashing by putting the target Electron in DFU. Then the device manager allows me an educated guess at what COM port to select in the serial monitor. I assume this depends on my remembering to click disconnect on the serial monitor before starting a flash test cycle.
I can’t find any option that relates to your comment about “explicitly assigning” the COM port. Advice? By the way, the device manager shows my 2 electrons as on USB ports 3 and 4 COM3 and 6 right now.
The GIT HUB Particle manual seems to assume a single electron on USB. Perhaps it needs a section on the impact of having two electrons plugged into USB ports. Thanks for help.
I'm sorry I can only provide German language screenshots, but I guess you'll be able to figure the respective steps.
In DevMgr right click on that Photon COM port you want to alter, select Properties and locate the respective tab, press Advanced Settings (or however it's called) and there you should find the drop down list.
After you selected the desired port number, you might get a warning that that number is in use already (can be ignored), and after you reset the Photon the new port should be active.
2 Likes
Was able to follow naming instruction but it was unsatisfactory because I have no idea about persistence. Is it something that lasts forever? Until the next WIN10 restart, until the USB cable is disconnected?
All that aside, lets move on or back to the original problem 0.6.0. I have become a 0.5.2 serial monitor master with no problem connecting and monitoring two Electrons simultaneously. I’m done with my project and now starting with a nice new Electron.
I followed the instructions for 0.6.0, verified installation with tinker and and the WEB IDE. I absolutely positively cannot get the build IDE (ATOM) serial monitor to connect. It displays COM8 as does the device manager. Of course, I have tried reboots. Why COM8 comes up instead of COM3 is a mystery. No other Electron is plugged in. Are new drivers required for 0.6.0? Suggestions. I can see from the thread comments that something in the serial interface has changed.
AFAIK not really new drivers (unless yours predate 2015Q4) but explicitly applying them to the device (update drivers with the same version).
About persistance, at least on my machine these settings stick when once done manually.
About your Electron not being accessible, that’s odd. Can you enter any of the serial commands (e.g. i, m, …) when in Listening Mode?
-
I don’t recognize your “i” and “m”. But, I’ve seen your constructive rebukes, “I found it using the documentation” so I tried and the closest I could get was Particle serial identify and list. Both of these return no serial devices found. I was careful to have my devices in listen mode. WIN10 listed them under PORTS in dev. mgr.
-
I’m at development standstill w/o the serial monitor capability. All I can say relative to 0.6.0 and 0.5.2 is that I’ve had much more success with serial monitor (in PARTICLE DEV) with 0.5.2. But at this point I believe my WIN10 is messed up. Why? Because when I go to the COM port advanced function in DEV. MGR, it lists COM1 -COM8 (except COM2) as IN USE even after a cold start w/o only 1 device (not a Particle but a benign Logitech goodie) plugged in. I have to have one device plugged in so that DEV MGR PORTS is displayed for examination. Any idea how I can get WIN10 clean up this IN USE mess? I’m certain that I only assigned COM3 using ADVANCE OPTION when I that explored that avenue. This is not strictly a WIN10 problem as the cause of the mess is TBD. Thanks
You can try to “uninstall” all Particle devices via an environment hack.
You can add a system environment variable DEVMGR_SHOW_NONPRESENT_DEVICES set to 1 and tick “Show hidden devices” in Dev Mgr
See https://support.microsoft.com/en-us/kb/315539
After that you can “uninstall” all Particle related COM ports (if you wish even with removing the drivers from your HDD on the last port) and try reinstalling them.
Maybe even redownload the drivers.
https://s3.amazonaws.com/spark-website/Particle.zip
About the “i” command, that’s the same as particle serial identify but without the need of CLI installed.
Just send “i” in any serial terminal program (I prefer PuTTY) and the device should respond (when in Listening Mode).
“m” should give you the MAC address of the radio module
1 Like
success thanks thanks thanks
any idea how it got messed up?
i plugged in a photon and it showed up in Dev Mgr. as electron. I assume that is ok???
the i worked great for electron… I’ll try it on the photon now
Yup, the mixup in naming is “normal”.
But I’ve no idea what caused the problem in the first place.
Updating a full system from one Win version to completely new one is a big job where loads of bit crumbs might fall off 