I have a problem with OTA updates with Particle-CLI. I’m using Windows, the last CLI release 1.28.2 (it happened with 1.27.1 too). I installed it from the CLI setup.
This is the log when I try to update the device.
>> particle flash XXXXXXXXXXXXXXXXX "Code.bin"
! Flashing firmware Over The Air (OTA) uses cellular data, which may cause you to incur usage charges.
! This flash is estimated to use at least 0.046 MB, but may use more depending on network conditions.
! Please type 0.046 below to confirm you wish to proceed with the OTA flash.
! Any other input will cancel.
? Confirm the amount of data usage in MB: 0.046
attempting to flash firmware to your device XXXXXXXXXXXXXXXXX
Flash device failed.
Send firmware to your device
Usage: particle flash [options] [device|binary] [files...]
-v, --verbose Increases how much logging to display [count]
-q, --quiet Decreases how much logging to display [count]
--cloud Flash over the air to the device. Default if no other flag provided [boolean]
--usb Flash over USB using the DFU utility [boolean]
--serial Flash over a virtual serial port [boolean]
--factory Flash user application to the factory reset location. Only available for DFU [boolean]
--force Flash even when binary does not pass pre-flash checks [boolean]
particle flash red Compile the source code in the current directory in the cloud and flash to device red
particle flash green tinker Flash the default Tinker app to device green
particle flash blue app.ino --target 0.6.3 Compile app.ino in the cloud using the 0.6.3 firmware and flash to device blue
particle flash cyan firmware.bin Flash the pre-compiled binary to device cyan
particle flash --usb firmware.bin Flash the binary over USB. The device needs to be in DFU mode
particle flash --serial firmware.bin Flash the binary over virtual serial port. The device needs to be in listening mode
Sometimes, few seconds after the reply, I see the update with the console logs (spark/flash/status: started, etc), and sometimes it’s never shown.
Why is this happening? How can solve it?
Assuming that eventX() and eventY() are realy fast returning (< 1ms - if not the risk increases) but processEventX() and processEventY() are rather long running you may still run into the problem outlined above.
One workaround would be
uint32_t ms = millis();
while(System.updatesPending() && millis() - ms < 120000) Particle.process();
This might still fail when the OTA update starts during processEventX() or processEventY() but should help in the other cases to keep your code from interfering while an update is being downloaded and applied (max. 2 minutes).
To have an option that also works in the edge cases, you could subscribe to the system event that indicates and OTA update and trap the code there.
Regarding the open issue, I don’t think anything has been done since.
Yes but I doubt that’s when your problem occures. Once the critical part has started application code will be stopped, but I think what you are seeing is that your code is still running prior the critical part (non-critical binary download and flash to intermediate memory) and hence impedes these parts from finishing successfully.
I also doubt that your event will fire while System.disableUpdates() is active, just the same way as System.updatesPending() doesn’t report a pending update when updates are disabled.
AFAIK the latter depends on the former and hence what is true for one is also true for the other.
BTW, since your event handler relies on out-of-order execution it might be required to mark your updatePending flag as volatile.