Since the firmware upgrade 0.4.6 I am unable to flash my Photon, even if I revert to the version of firmware it currently runs, being 0.4.5.If I try to run the code I have written under 0.4.6 I get compile errors, stating the ‘Spark’ is deprecated in several instances of the code. OK, so if I revert to the version I know works for my application in the WEB IDE, I should be able to flash that my code until I can modify and test my code with the new “Particle”. statements. Problem is NOTHING will flash to my device - not even “Blinky” - whether I select 0.4.5 or 0.4.6.
Possibly the most frustrating thing about this is that the WEB IDE declares that the flash is successful, but I see no magenta flash or other indication the code is loading - and in the case of Blinky, I see no blink - definately NOT successful…
Can anyone help me on this?
Have you tried via Safe Mode?
If this also doesn’t help, have you got Particle CLI installed?
I have CLI installed, but the unit is physically 15 Kms away. I have someone observing it to advise if the flash happens. They are not able to set to safe mode as the unit is in an enclosure - and frankly, they are not really technical people. Are you suggesting I load code via the CLI?
OK - have run up a local device, in safe mode and managed to flash blinky to it. This is something - but not practical for the units I have in the field. Thanks to @ScruffR for the suggestion - but I’m still in trouble here. These are commercial prototypes.
Update: with the local unit, I have reset from safe mode to normal operation and managed to flash the code I need using build 0.4.5. I will have to go onsite to verify if the same process works on the other device - I guess I will then have to modify the code to suit 0.4.6 and go onsite again after testing. I sincerely hope the Particle guys do not change their name again…
Last Update: with the local unit still in normal operation, a second flash failed - but gave the successful message on the IDE. Returning it to safe mode and repeating the process above worked. This is really disturbingly unstable - I will try the process on the unit onsite and see if the same processes occur.
This is somewhat brave, to push a system firmware update over this distance 
Have you got any idea what went wrong? If the system FW got at least flashed properly?
Is your remote Photon online?
What errors do you get that can’t be easily fixed with a search Spark and replace Particle?
Sorry, I may have been unclear. I did not realise a new firmware version had been released. I had modified my code and tried to load it to my remote unit - it wouldn’t compile due to the 0.4.6 update. So after mucking around, I found that I could manually (at the IDE) flash to the remote unit using the version I know works (0.4.5). this did not work - got successful message but code not updated. I then hooked up the local unit and events occurred as above. For my purposes, it is imperative that I can use the WEB IDE to update code for units in the field.
I’ll post the errors a little later - thanks @ScruffR for your continued help.
One thing you might want to do to prevent a new system firmware to be flashed by accident is, to avoid the latest (0.4.6) version, since this will get pushed forward each time a new release goes public.
Rather go for 0.4.6 explicitly.
Could you just try the Blinky with 0.4.6? Maybe getting your device up and running again with 0.4.6 is easier than down-grading again.
Hi @ScruffR - I’m completely confused. If I understand what your saying, I have accidentally upgraded my Photon to ver 0.4.6 - and I can assume this happened when I tried to flash Blinky to the device I have set up locally (because my main code would not compile). OK - so that means that firmware updates are now happening over the air (not via DFU or CLI) and that by not specifying the version I know works (0.4.5) in the IDE prior to attempting a flash I will update the Photon to 0.4.6?
In short - firmware updates are completed over the cloud. If I update to 0.4.6 all future upgrade will happen automatically. If I don’t update, there’s a chance my code will not work on future cloud iterations. Is this right?`
One thing that may help. Assuming I have “accidentally” updated my Photon - could I replace the new version (0.4.6) with the old (0.4.5) by using the DFU process?
Sorry for confusing you 
First, yes system firmware updates can be done via CLI, DFU and OTA as a semi-automatic process, when you send a new application/user firmware that requires then new system firmware. And this procedure was already introduced along with 0.4.5.
But ...
... what I assumed from that was, that you tried to flash some code via Web IDE to your remote Photon while having last set latest (0.4.5) as target version.
But since 0.4.6 has been released latest (0.4.5) got automatically pushed up to latest (0.4.6) causing your Photon to auto-upgrade to 0.4.6.
New system firmware only gets delivered to the Photon when you have set the build target for your device accordingly and the target device hasn't already got this verion on board.
But this only happens for that one device that you got selected as target device and no other device of yours.
Now so far - and this is my current understanding still - if you flash 0.4.5 application firmware, which doesn't use 0.4.6 new features, this should still run without issues.
There is some distinction to be made.
If you had already selected 0.4.5 (and not latest (0.4.5)) in Web IDE as targed version, you will still be building with 0.4.5 and never be upgraded automatically.
If you had latest (x.y.z), each time a new releas gets published and you flash some application firmware, the new system firmware will be delivered with it.
And if you now select e.g. 0.4.4 as target version for a device that already has 0.4.6 the application firmware should still run, but if your firmware relies on features (or bugs) that were in the old firmware and the IDE knows it, your device should get downgraded too.
But there should not be any need to go back to an old system firmware 
Any errors that you may have only due to the upgrade should be easily fixed. Just post your error output and I'll have a look.
Hi @ScruffR, I realise by not keeping absolutely current on what's happening, it seems I have inadvertently pushed the new version 0.4.6 to my local test Photon - my fault I guess. I have confirmed the remote unit has not been upgraded to the new firmware - and I will be able to update my code changes (written for version 0.4.5) by specifying that version when flashing from the Web IDE. The problem I have is that the IDE "defaults" to the latest build - whereas I think some sort of warning should have been in place. This is why I could not flash the remote unit in the first place (code would not compile). I though there was a problem with the unit and was going to flash blinky to confirm it was OK (though I could see it operating on dashboard). Luckily I didn't - as blinky would compile under the new firmware and updated my remote unit which will only operate on code written in 0.4.5! Trap for beginners? Yes.... But I think better safegaurds could be put in place. Anyway, I have (with your help....thanks) averted the crisis - but have a Photon that can't run my field code - which leaves me in the position that I have to re-write the code for version 0.4.6 - to suit one Photon unit - or upgrade all the remote units.
You mentioned that;
This has proven not to be the case in my experience - the upgraded Photon definitely will not run the previously proven code - though it may contain the "bugs" or "features" you mentioned. Regardless, it definitely did the job - now it doesn't.
So if anyone can confirm if doing a DFU upload of ver 0.4.5 to a unit running 0.4.6 will work - I'd really appreciate knowing.
Can you give me some code that runs on 0.4.5 but not on 0.4.6 that would not merely require search for Spark replace with Particle for testing this out?
Hi again @ScruffR, Firstly, I am a project manager for a commercial project - and while I love playing with the Photon, I am a newbie (at best) with programming - the actual programmers cannot release any of this code - sorry, because I really appreciate your help and want to contribute to the knowledge of the greater community. What I can say at this stage is that in the physical config the Photon is communicating by serial to another micro-controller, the Moteino, based on the ATMega328 - and effectively an Arduino clone running at 3.3v with a Hope RF unit.
The only connection (between the two units) is serial, which is directly wired (Tx to Rx and visa versa).
In the code I have deleted a line that was causing a problem that caused a CloudClass::variable error - and then replaced every instance of Spark. with Particle.
So far so good - the code complies under 4.06
After flashing it, the Photon (also running firmware 0.4.6) goes into a constant cycle of resetting about every 6 seconds while there is any serial communication between the two microcontrollers. The reset process often involves multiple red flashes between “finding” the internet again.
If I disable the serial comms on the Moteino side (in software - not physical) - all of a sudden everything is fine. The Photon will broadcast to a webhook reliably.
I should also note, in case it is of value - that the Photon is taking analog readings on A0 from a pressure sensor - if the sensor is disconnected, WiFi becomes unstable - and ends with constant flashing green.
In the same test rig, a (admittedly different) Photon running firmware 0.4.5 and including the Spark. (rather than Particle.) changes that I did for the 0.4.6 version communicates reliably with the Moteino - and has been doing so for about a day now - disconnect the sensor, stop / start the serial no problem. My production field model has also been reliably running on a Photon that has 0.4.5 (and the original code) in a prototype rig (identical to the test rig) for 3 weeks.
I know this sounds like some sort of construction problem / loose wire / component or bad earth thing - but I have repeatedly swapped the photons in the same rig to try to find a hardware or construction issue but the results are the same every time.
I understand that you can't share your production code with just anybody (especially since Elites are "only" enthusiasts not affiliated to Particle and not bound to non-disclosure agreements), but it would help tho'
Since I've no feeling for the sice of your project and the impact of the recent update on available flash/RAM space it would only a blind guess but maybe worth considering.
But if you need Particle pro help, we can ping @corey to get in contact and offer some official help.
Meanwhile for this error
There are two common reasons for this to rear its ugly head:
One is the deprecation of Spark, so using Particle.variable() instead would solve this side of it, but if your variable is a STRING then you either have an erronous ampersand & in that line, or you're using a String object as source for that var.
Maybe you could just post the one line of code and the declaration of the base variable without giving too much of your project away.
Are these actually red flashes or could they be three orange flashes?
If they in fact are orange you mustn't be worried as this is a self-healing attempt to cure an issue with wrongly falling into Safe Mode.
If you actually see red, then it should be a SOS pattern (SOS ... x red flashes ... SOS) - in this case we'd need to know how many (x) red flashes you see between SOS.
For your unstable WiFi the cause could be that your code does not allow for servicing the background cloud process often enough.
To get around this you could either
- ensure that the code is writen less blocking (best option), or
- you add
Particle.process()calls wherever your code might get occupied for a longer while (e.g. loops that do the serial communication might show "unpredictable" delays), or - you test out the beta multithreading feature by adding this line at the top of your mainproject file
SYSTEM_THREAD(ENABLED)
Could this be due to non-error-tolerant coding when processing the analog result?
I'd be rather sorry if the update itself broke your code, but your input would definetly be very valuble to put the finger on such issues and then get them sorted.
So please keep your results coming 
Sending you a message offline in a PM
Hi @ScruffR and @corey,
The offending line that caused the CloudClass::variable error was:
Particle.variable(“result”, &resultstr, STRING);
We tried this in the unit running firmware version 0.4.6 with the outcome as described earlier. Not an issue now as we have removed the line completely - and as stated the code will compile in the IDE (ver 0.4.6) with Spark. changes to Particle. in all appropriate places. Meanwhile, I have hardwired a vero board test rig with sockets for the Photon and Moteino and am running some mods on our earlier and proven code on a (new) Photon -running firmware ver 0.4.5, which so far seems solid. After I have tested the new mods (maybe 24 hours) I will try to recreate the 0.4.6 (serial to the Moteino crashes the Photon) fault using the new rig - if it fails there it will have failed on two separate rigs and I will assume there is a problem with the new Photon firmware version. My software guys will also try to recreate the serial interface problem using some simple test code and a 3.3volt Arduino pro-mini clone - and if the same thing happens I’ll happily forward that code. If not we’ll look closer at the Moteino - but it seems unlikely it could be the source of the problem. Regarding the observation that there was WiFi instability if the Analog (A0) cable to the sensor was removed - there is a chance that was a bad earth somehow causing that problem - again, I will test that on the new hardwired rig though it would be spooky that I repeatedly swapped the photons on the original test rig and recreated the problem every time. Guess construction is funny that way…
Hi @DRCO
I just wanted to make sure you understood that this line has a programming error: you do not need the "&" for a STRING (char array) variable and a recent compile check now makes sure that you cannot make this mistake.
Thanks - it’s good to understand the actual problem. Greatly appreciate your input, as ever @bko