I have a photon I’m having real trouble getting to flash OTA.
I hit the flash button in the ide. The system says “Flashing code”. Nothing happens on the photon. The flash process times out and says “Flash unsuccessful”. Immediately after that I see " Last Event: flash/status = started", at which point the photon shows a slow magenta blink roughly 5 seconds on, 5 seconds off (that’s on/off - not breathing). Occasionally there will be a short burst of fast magenta flashes. This goes on for up to two minutes, then the device restarts. As far as I can tell the flash update has failed, and its the original code running.
Whats going on?
What system version firmware are you running on your photon and what version of the firmware are you building for on the web ide?
Lots of magenta flashing like the pattern you described usually means the photon is trying to update itself to the firmware version you are trying to send it.
Have you tried updating the system firmware on the device manually with CLI (which uses dfu-util)?
$ particle update
$ particle flash --usb tinker
1 Like
I know what the firmware version update looks like - this is quite different. This is a device I’ve been using for half a year - the firmware is at the correct version.
Did an update and reset to tinker. (Not field practical) . first flash of code worked (VERY different magenta pattern), then back to weirdness.
I occasionally see the SOS with a “stack-overflow” code after the magenta blinks have finished.
There is a piece of code that can take 30secs to break out back to the main loop, but I thought running threaded meant the system wasn’t blocked. Could that be stalling the update long enough for the OTA flash to give up then get screwy?
I’m having the same problem all of a sudden, although not seeing any SOS indication. I just get a very slow blinking magenta when I try to flash OTA after the flash attemp times out.
I’m still trying to debug this a bit but this seems to only happen when I am in the middle of running a blocking function from loop() even though I am running SYSTEM_THREAD(ENABLED).
Adding Particle.process() in the blocking code (a mostly endless while loop) seems to have fixed this… but I’m not sure why this is necessary if system threading is enabled.
The OTA download can be handled in the background, but the actual flashing may only kick in when the application is in a “safe” state.
It would be bad if it would happen during an EEPROM write or any place where the user data or device integrity would be at risk.
“Signalling” such a safe state is up to the user by allowing the cloud process to run in the application thread and not just in the system thread.
e.g. Particle.function() and Particle.subscribe() handlers also need to be run in the app thread for a similar reason.
1 Like
Meaning… my solution of adding Particle.process() was the correct one as long as i’m sure I stuck it in a place that was safe to do so?
@abelsm2, meaning yes, your solution was correct. What @ScruffR was saying is that if the system thread did an OTA at any time, it could jeopardize user code (eg EEPROM writing), so running Particle.process() yeilds processing to the system firmware in a user-controlled fashion, as you surmised from your solution. 
1 Like
Which leads me to two questions:
- roughly how much time is consumed in Particle.process()? I know this is going to be variable, but a rough guideline would be helpful.
- is there any way to know the OTA update has been downloaded and is ready for flashing?
These would be useful for balancing a time critical operation against responsiveness to OTA updates and event handling.
What about the “stack-overflow” I see sometimes? I’ve also seen “hard fault” on occasions.
thanks @peekay123 and @ScruffR!
I decided I was being lazy and update my code to eliminate the blocking nature of the function I was using so it would constantly return control back to loop(). This also solved the problem and felt cleaner.
Both your explanations helped for future designs though!
2 Likes