I am having an issue in a battery-operated Electron system where I am starting, doing a few things, reporting to the cloud, then powering down again.
I have an event attached to firmware_update that is supposed to notify me to delay the shutdown while a firmware update occurs, but I am finding that it does not trigger until after the device is already shutting down!
Is there a way to move this check sooner in the process or is there a (hidden) system variable I can check to say whether the firmware version check has been made? Leaving the device on and just waiting around for a thing to happen (maybe) isn’t good coding practice.
System thread is enabled, I am quite cautious to insert Particle.process() in anything that blocks, and I have also refactored the loop() into a state machine so that it can fall-through a number of times during execution. None of these things seems to affect the timing of the firmware_update event.
(NB4: System.updatesPending() is probably not going to be useful since [its documented function] is to find whether an update has been rejected during a period of System.disableUpdates(). Not an enterprise customer, so this is irrelevant anyway.)
I appreciate the documentation isn’t as clear as could be on this area. Have you tried checking for reset and resetpending?
Something like this:
void handle_restart_events(system_event_t event, int data)
{
if (event == reset)
{
isResetPending = false;
}
else if (event == reset_pending)
{
System.enableReset();
}
else if (event == firmware_update && data == firmware_update_complete)
{
isResetPending = true;
}
else if (event == firmware_update && data == firmware_update_begin)
{
//Software Update In Progress - set a flag to ensure device does not shutdown
}
}
In my applications I have run states (standby) where software updates are permitted - I ensure that updates are enabled and disabled accordingly going into and out of standby. The isResetPending flag is used to ensure SPI bus access isn’t started when a reset could happen in the middle of a transaction.
System.on(reset_pending | reset, handle_restart_events); // edited per below
...
void handle_restart_events(system_event_t event, int data) {
appLog.info("Restart event occurred!!!");
if (appLog.isInfoEnabled()) delay(3000);
}
but it this message does not appear in the log, probably because System.sleep(SLEEP_MODE_DEEP, long seconds); is what is initiating the disconnection, rather than some soft reset.
I thought the event flags had to be added together - like this? System.on(reset+reset_pending+firmware_update, handle_restart_events); //register event handler
Maybe that explains why there was no output?
ORing is the more professional and safer way to do it - but it should actually be the binary OR | not logical ||.
These “flags” may not always be single-bit flags but actually combinations of finer granular flags.
While ORing a combinatory flag of 0b1001 | 0b0011 = 0b1011 (both share the least significant bit set) will render all bits of both set, adding them will not 9 + 3 = 12 (0b1100).
Thanks for being corrected - you are 100% correct. I am of course following the example in the reference documentation and in any case the event values are all 2 power n so no two events share use of the same bit. Use of || rather than | is the real issue here!
// listen for Wi-Fi Listen events and Firmware Update events
System.on(wifi_listen+firmware_update, handle_all_the_events);
Have you tried the code snippet I posted? The whole thing is a bit more subtle than it seems and I received some help from Rick. I think the problem was that once the event reset is recognised then there is no time to do serial output.
BTW, isResetPending = false; should be set after the System.on();
I already have this code in use, which is supposed to block the turn-off from occurring. The problem is that the firmware_update event doesn’t come in until AFTER the shutdown has begun.
I am checking for it before shutting down.
void firmware_update_handler(system_event_t event, int status) {
switch(status) {
case firmware_update_begin:
gFirmwareUpdateStatus = FW_UPDATING;
appLog.info("Firmware update beginning event was triggered.");
break;
case firmware_update_progress:
gFirmwareUpdateStatus = FW_UPDATING;
appLog.info("Firmware update progress event was triggered.");
break;
case firmware_update_complete:
gFirmwareUpdateStatus = FW_DONE;
appLog.info("Firmware update complete event was triggered.");
break;
case firmware_update_failed:
gFirmwareUpdateStatus = FW_DONE;
appLog.error("Firmware update failed event was triggered.");
break;
default:
appLog.warn("Unknown firmware_update_handler status %i", status);
break;
}
}
@rickkas7 - Any thoughts on this? It’s almost as if “firmware_update_begin” simply happens arbitrarily whenever the flag can be set so this only helps to detect when an update begins, which leaves us in an indefinite holding pattern (or arbitrary delay). Is there a method of programmatically determining if this check has been ran?
One additional data point: This issue only seems to arise when SYSTEM_THREAD(ENABLED);
When it is disabled, the update event still comes in after the shutdown has begun but when the update packet comes in, the update process seems to take over the device and force itself into an update. Notably, I am getting an update_failed event, but the update seems to be working anyway.
void turnOff() {
appLog.trace("turnOff()");
waitForFirmwareUpdate();
ledPowerOffAnimation();
appLog.info("Turning off after a 3 second log flush delay--MARK.");
if (appLog.isInfoEnabled()) delay(3000);
while(1) System.sleep(SLEEP_MODE_SOFTPOWEROFF, LONG_MAX);
}
// Disables the LED thread and plays a POWER OFF blink animation
void ledPowerOffAnimation() {
appLog.trace("ledPowerOffAnimation()");
os_mutex_lock(ledControlMutex);
for (uint8_t i = 0; i < 10; i++) {
appLog.trace("outer loop");
for (uint8_t j = 0; j < 2; j++) {
delay(200);
if (j) digitalWrite(PIN_LED, HIGH);
else digitalWrite(PIN_LED, LOW);
}
}
digitalWrite(PIN_LED, LOW);
}
The update is taking over during the short delay in the ledPowerOffAnimation()!
Ideally we should have more control over the process than this, even though disabling the system thread does seem to lead to a more aggressively enforced update process.
This has more to do with the fact that the system thread is preventing the application thread from shutting down, and is still down to timing alone rather than a guaranteed version check.
I have major concerns that anything I do will stop working as soon as logging is turned off.
We’ve been trying probably everything possible for that, “planned” updates NEVER worked for us. You may have to wait for minutes before the update happens (unless updateEnabled is called before connecting, but the thing is, you usually DON’T want the update to interrrupt whatever the device is doing (sampling, saving, etc…) and that WILL happen if you let the system decide to update. We even tried to enable updates at the end of our processing, wait for minutes… never happens… another attempt was to force a connection refresh (publishing to some event I can’t remember, as mentioned in another thread, I can find that for you…) but that didn’t work either.
How we ended doing it: easy, we send a remote command (programmed) to put the device on SAFE mode when it connects, and we force the firmware from the Particle console. Pretty lame, to be honest, especially if you deal with more than the 20 or so devices we have on various sites…
We haven’t tried the enterprise update either, because I don’t think there should be an additional cost for a feature that’s supposedly part of the Particle benefits, updating firmware.
There’s a paradox here: Particle is advertised as amazing on remote locations (which it is), but then most of the time you have to put the device on sleep to save battery, and then you can’t benefit of the firmware upgrade feature so efficiently. The way it should work is, you would send a message to Particle if an update is available, to say: let’s do it! Then it would (magically?) happen…
Anyways, as I said, just my two cents. Try SAFE mode if nothing else works (with a drawback, however: when in safe mode you lose control over your device, especially if connection becomes unreliable…)
@peergum I think you’re right on with a lot of this.
All I need is a way to know that the system firmware hasn’t wrapped up its business yet so I can hold for it. There is still an asynchronous Time Sync messages that comes in after I am ready to shutdown, as well…
There are clearly things that the system (either the device or the server) has queued up but I have no way to know that.
–
I’m not even terribly concerned with the main operation getting interrupted… I just need some kind of view of what the API is trying to hide from me.
You need to make sure that you are calling Particle.process() before you make any decisions based on the status of the firmware update flags. In SYSTEM_THREAD all system event handlers are called during Particle.process() only. There is no push event into your thread.
(with a drawback, however: when in safe mode you lose control over your device, especially if connection becomes unreliable…)