OK, so I got the latest DEVELOP to compile. First impressions:
Using manual system mode, it wouldn’t connect to WiFi with “WiFi.connect.” Power on -> white breath -> blue -> blue fadeout -> LED off (I’d called for LED control). My project code really wasn’t working.
Reverted to normal system mode. Had to give it WiFi credentials to get it to connect (weird). Blinking-connecting pattern a LOT different. TCPServer/TCPClient appear to function, at least as well as they used to. System stability is an issue: after running for about 5 minutes (constantly scanning FLASH via the FlashEE library), the LED started unevenly blinking cyan. After about 15 seconds, the Core resets. Repeatably. Yes, I know, I’m running my full project, not a test debug build.
EDIT: still doesn’t have the ADC fix to remove slow-interleaved mode.
EDIT: Applied CC3000 patch and deep-update to the Core I’m currently using. I have a couple Cores, and don’t recall which one(s) I applied the updates to. That’ll get you every time.
It still has an added “blue flash” when starting. The upside is that sometimes it connects to WiFi in two seconds! Power up -> (1sec) white breath -> blinking green(1.5sec) -> blue(1sec) -> off (I do have control of the LED) -> a few seconds later after WiFi connection is attained, my code regains control of the LED and turns it back on. (Code is running during this period.)
This is with code that in the month-old LATEST and Particle Dev IDE, would sequence Power up -> (1sec) white breath -> code blinking green 'till connected, then solid green.
EDIT: Another problem: WiFi.connecting() returns FALSE even when it is connecting (I.E. WiFi.connect() has been called in MANUAL mode). This code worked properly with the month-old LATEST and Particle Dev IDE.
@mdma: I’m not sure I really want to spend all day trying to definitively pin down these firmware bugs…is there some official assurance that my efforts won’t go to waste? Today I found that there were multiple posts over a year ago (particularly this one: Why dual slow interleaved?) regarding the dual slow-interleaved ADC code causing low reading errors–and that issue still hasn’t been fixed, even in the DEVELOP branch. Sorry if I sound like a rant, but IMO this is a little too long to fix such an easy issue.
Did you update via USB? If not please double check that the firmware has in fact been upgraded. (You can try the 0.4.4-rc.5 version which prints the exact version string when pressing ‘v’ over serial.)
Nothing there has changed since rc.3 so I’m fairly sure it was a problem updating your code. But great to hear that it’s fixed for you after the rollout.
The default antenna choice just bit me. The area lost power, when it came back, the devices came online with the old behavior of AUTO, found new firmware that changed the default behavior to INTERNAL, and now I have to drive 4 hours one way to manually flash my devices. They’re inside grounded metal enclosures, so there is absolutely zero chance of that internal antenna doing anything useful.
Timing is everything, I guess. Power failure just hit at the wrong time.
I don’t understand why AUTO was ok before, but not now.
Sorry about that! It was a tough call, we’re finding that the default AUTO antenna behavior in wiced actually makes performance much much worse when no external antenna is attached.
We’re still testing a custom AUTO behavior that doesn’t have the wiced auto issue. We didn’t include it in the rollout because it’s still being tested, but we wanted to get the newer 0.4.4 version out to as many people as possible soon, since it has so many improvements. Sorry the change of auto antenna selection bit you though!
no worries. someone gets bit at every upgrade and i have been lucky to have escaped unscathed from many previous upgrades on many previous platforms for many years, so it was my turn.
AFAIK it wasn’t said that it would be released with this FW but that this FW release was a necessary prerequisite for the rework of the library, which will be published some time after the release.
That’s @peekay123’s work. I’m pretty sure a release is imminent, since he too was eagerly awaiting this release. He’s not a Particle employee, and his work (that library) thus isn’t linked to any updates from Particle. Knowing him, it probably wont take too long
How does one reflash? this is a new photon that I literally just plugged in, through the app it said it was updating the firmware … and this is where it’s at
Photon System Firmware Update fails and Photons just breathe Magenta…
I have one photon I’ve been using since June, was working fine. Had been OTA updated to 0.4.4 rc2 two weeks ago, still worked fine.
I received two new photons yesterday. When they were configured I got the warning about a long firmware update. They spent a long time flashing Magenta but when the finished the v command did not give the version string, so I assumed that didn’t work.
I then used particle dev to flash my firmware to all three photons. They all blinked Magenta for some period of time. Now all three breath Magenta and I am unable to communicate with them through the cloud. They show up as on-line but getAttributes returns this
“wl0: Nov 7 2014 16:03:4…230.12 FWID 01-9e9014ca”
With no attributes or functions reported.
I’ve tried a factory reset, but end up in the same place after it is all done.
My photons are now un-useful. Any advice on how to recover from this?
Un-useful! Oh dear, that’s definitely something we want to avoid. Photons should be nothing short of awesome!
Could you please retry flashing your firmware? If the system updates don’t take, then reflashing firmware (via CLI or Build) is the way to trigger a new attempt to flash system firmware.
Your new unboxed photons may have to go through several updates before the final system firmware is deployed.
We will continue improving the auto update system going forward so that repeat flashing of your application isn’t necessary.
Photons should be nothing short of awesome! 