I was going to revive this other thread: Breathing Cyan but device doesn't show up/react [SOLVED] I had a similar experience but I guess I will start anew since that one is very old.
I bought a Spark Core back in 2013, tried to use it once but had some problems, put it aside and am trying again now.
I tried many things, probably close to two days of work now:
tried to get it set up via an Android 5.1.1 phone (app doesn’t find the Core and I did check network parameters like channel number, 2.4GHz, SSID broadcast, WPA2, on local network with very strong signal from Netgear R7000 router and no other traffic) using the Spark Core app not the Particle one (I tried both)
tried to set it up via USB from Mac OS El Capitan 10.11.3 (here I ran into npm installation issues on my Mac so couldn’t continue)
tried to set it up via a Banana Pi (like Raspberry Pi) but again ran into either node or npm compatibility issues with the OS
tried to set it up via an old iPad but that failed due to the iOS being < 7 and I couldn’t update it (Gen. 1 iPad)
actually bought a copy of Parallels to try to set up via Linux in a VM. I had a Linux based off of downloading the .iso image and another VM installed automatically by Parallels. After significant problems (e.g. the Mac’s wireless is inaccessible from the VM, only a USB wifi dongle can be seen from the Linux virtual OS) I made some progress here.
One very perfidious, insidious thing was that sometimes after trying something the serial communication would silently get blocked. Like a command would work then sometime later, stop working. I had to restart the VM, cycle power on the Core and once I even had to restart the Mac to get the serial communication working again. This bug was extremely frustrating while testing combinations of parameters or commands to see what worked and what didn’t.
Anyway, “sudo particle setup” never worked. It would either block after asking to scan for wifi, or if it didn’t block sometimes it said no permission. If I told it not to scan and I entered SSID and password manually it would do something, the Core light stopped flashing blue and I think it might have done a restart but then the magenta LED came on solid, which I take to mean no network connection.
I also tried using “sudo particle identify” and “sudo particle serial wifi” to get the device ID, then I went to build.particle.io/ where I could do “Add” to claim the device. I’m not going to go into details here but this also did not work, as far as I could tell. It is listed in the Android App but I guess that’s just because I’m logged in to particle.io and it got the added device from there–it doesn’t mean the device is actually connected via wifi.
I realized part way through this in fact my router is acting like a firewall. I can see how that would prevent me from running the “Flash” command from the build.particle.io web page but I think most of the other problems I had are not related (flaky serial communication, android app not finding Core on local network, etc.).
Any ideas? My idea tank is running dry and my frustration tank overfloweth.
I’m looking at setting up port forwarding on my router; more frustration and time lost. I am for sure not turning off my network’s firewall functionality in order to use a Particle device. Re: port forwarding, can anyone suggest a way of getting the MAC address of a Core through the command line (as there is no wifi)?
(as a comical note: when I click “Create Topic” to post this–I get “503 Service Unavailable: Back-end server is at capacity”…fantastic)
thanks for the reply & tip. Unfortunately, that command fails:
$ sudo particle monitor (my_device_id)
polling server to see what devices are online, and what variables are available
? Which variable did you want? (Use arrow keys)
readline.js:945
throw err;
^
TypeError: Cannot read property 'short' of undefined
at Prompt.render (/usr/lib/node_modules/particle-cli/node_modules/inquirer/lib/prompts/list.js:94:69)
at Prompt.onSubmit (/usr/lib/node_modules/particle-cli/node_modules/inquirer/lib/prompts/list.js:116:8)
at AnonymousObserver.Rx.AnonymousObserver.AnonymousObserver.next (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:1535:12)
at AnonymousObserver.Rx.internals.AbstractObserver.AbstractObserver.onNext (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:1469:31)
at AnonymousObserver.tryCatcher (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:63:31)
at AutoDetachObserverPrototype.next (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:5782:51)
at AutoDetachObserver.Rx.internals.AbstractObserver.AbstractObserver.onNext (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:1469:31)
at AnonymousObserver._onNext (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:4234:13)
at AnonymousObserver.Rx.AnonymousObserver.AnonymousObserver.next (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:1535:12)
at AnonymousObserver.Rx.internals.AbstractObserver.AbstractObserver.onNext (/usr/lib/node_modules/particle-cli/node_modules/rx-lite/rx.lite.js:1469:31)
but I see now there is actually a "particle serial mac" command which should give the MAC address. It, perhaps not unsurprisingly, fails also:
parallels@ubuntu:~$ sudo particle identify
Your device id is (my_device_id)
Unable to determine system firmware version
parallels@ubuntu:~$ sudo particle serial mac (my_device_id)
? Which device did you mean? /dev/ttyACM0 - Core
! serial: Unable to get MAC address of a Core
parallels@ubuntu:~$ sudo particle serial mac
! serial: Unable to get MAC address of a Core
parallels@ubuntu:~$
It wasn't clear if "particle serial mac" required device id as a parameter so I tried with and without. Both failed.
I can’t get the MAC with CLI either, but via serial I can.
But you need to know that particle serial monitor doesn’t allow you to send the required “m” command. Rather use CoolTerm or something similar on /dev/ttyACM0
I guess it’s a philosophical question why there’s a “particle serial mac” and a “particle serial monitor”, neither of which seem to work. They should have included some more commands like “particle activate anti-gravity” and “particle invisibility shield-on”.
I will try using “screen” in Linux to communicate to the serial port…but at what baud rate?
They do work, but not for all cases particle serial mac works for the other devices, but the Core does not work with it. particle serial monitor works as a monitor to observe what's coming from the device, you just can't send data as you could with a serial terminal.
Since it's a USB virtual serial port there is no baudrate required. Communication will always use USB 2.0 speed.
But there are some special baudrate settings that trigger special modes (but not for Core).
See https://docs.particle.io/reference/firmware/electron/#begin--1
Screen (linux command) didn’t work but Putty sort of did. Sometimes the Core would respond to inputs typed into the terminal, sometimes not. Restarting the core, restarting the putty session would often help although a couple times I had to reboot the virtual linux machine. I don’t get why the serial port blocks like that. Is there any way to have the linux OS send some kind of reset to the serial port to unblock it? Anyway, the “m” command never caused any output to show up in the Putty serial terminal whereas at least if I typed “w” I would then be asked for wifi SSID and password. I entered that info but the Core LED switches to solid magenta after a very brief pulsing cyan. It could still be my firewall blocking traffic although I sort of think it’s the Core given how flaky it’s been so far.
I got somewhat farther I think. One key thing I did was after the Core rebooted after entering wifi credentials, and started pulsing cyan (which it always did for about 1 second before switching to solid magenta) I hit enter (this refers to the “Press ENTER when your core is breathing CYAN” line in “sudo particle setup”). It went further and starting doing the rainbow flash. It still was stuck somehow so I tried a factory reset like in How to do a factory reset and started all over again and it finally seems to have added it to the build.particle.io device list. It must have had an Internet connection if only briefly.
After getting it to show up in the device list but while it was still in “shouting rainbows” mode I tried to flash the “blink-an-led” demo code on build.particle.io but that failed, with a timeout. I then tried restarting the Core and flashing the blink-an-led code again but that also failed with a timeout. Also, when the Core restarts it’s final LED resting state is solid magenta. I also tried using both the Particle and Spark Android apps on my phone and although they claim to see the Core, there is no communication–I can’t reflash Tinker, I can’t blink the led using pin D7.
Maybe it’s just a defective Core? I mean, it’s extremely effective at causing enormous frustration, but not so effective at anything else.
Any suggestions of what to try next?
ok, I think, after about 15 hours of absolute frustration, it seems to, temporarily at least, be working.
I tried a few more command line things:
sudo particle update – didn’t help
sudo particle flash (mydevicename) tinker – didn’t help, didn’t even work but I forget the error.
sudo particle flash --usb tinker – didn’t work, the error was “invalid dfuse address”. Some other posting indicated to upgrade dfu-util. Upgrading via the apt-get mechanism failed, it just stayed at 0.5 no matter what, I even tried “sudo apt-get remove dfu-util” and then “sudo apt-get remove dfu-util”. Finally I decided to build dfu-util from scratch via the build instructions on http://dfu-util.sourceforge.net/build.html. The build seemed to work but “dfu-util -V” showed I still had the old version even after doing “sudo make install”. Fantastic. So I manually deleted
/usr/local/bin/dfu-prefix
/usr/local/bin/dfu-suffix
/usr/local/bin/dfu-util
and re-ran “sudo make install” and finally got the new version when I did “dfu-util -V”.
I suppose there’s some way of doing make install to overwrite or maybe I should have done the “make maintainer-clean” command I see now for “If you later want to update to latest git version, just run this” in the dfu-util build instructions.
Anyway, the tinker flash then worked:
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device…
ID (deviceID…)
Run-time device DFU version 011a
Claiming USB DFU Interface…
Setting Alternate Setting #0 …
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash "
Downloading to address = 0x08005000, size = 82864
Download [=========================] 100% 82864 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state
Flash success!
After that I could use the Android app to make the LED turn off and on and also download the blink-an-led sample code from build.particle.io.
I hope the rest of my Core experience is less frustrating and time-consuming…
I (this weekend) repurposed a core to do something new and spent a lot of time getting it to work with libraries which have been since upgraded for Photon.
My advice is to “keep calm and carry on”.
Get your Core doing something good and move on to Photon…
I’d trade $19 for my several hours of frustration!
I should have checked for new boards like the Photon. It looks a lot better than the core. I went to order one now but shipping (for where I am in Europe) costs more than the board–totally crazy for a little PCB you could stick in a padded envelope and ship for a few dollars. I suppose they want to eliminate problems due to damaged goods but they’re also eliminating orders. I probably will ship to someone in the U.S. and have them ship on in a padded envelope for a few $ but it’s annoying.
But you need to compare prices and shipping costs e.g. Watterott in Germany is amongst the cheapest for the Photon, but I don’t know what delivery is to Switzerland.
Thanks. I think I was still in frustration-mode (the Core pushed my FRST button too long and too many times : ) ). I should have thought to look for European distributors. Watterott & exp-tech.de are both about 24.50 euro / $27 with shipping for a Photon which is actually cheaper than what I’d pay in the states (19+8.71 shipping)…amazing. Ordering in Germany is fine since I’m near the border. B.t.w. …how did you know I’m in Switzerland?
