Dashboard + disableUpdates() causes user code to stop running

Cloud
1

Adding product to dashboard causes code to stop running if disableUpdates() was used.

I noticed that some of our photons would spend long stretches being unresponsive. For about 10 seconds the code would run, then for twenty seconds our user code loop() did not seem to execute. No serial output. It appeared to hang between loop calls. During this time the phone LED was breathing cyan. Towards the end of the pause, it would briefly switch to fast flashing cyan. After that it would return to slow breathing cyan, and run user code for a few seconds before the whole process would repeat. Notably, there was no SoS, and user code was not reset to the beginning - it just continued where it left off.

The problematic behavior was stopped when removing that photon from the dashboard, then restarting the device.

We suspect that the problem relates to the following:

  1. The dashboard was trying to upgrade to a new version of firmware

  2. our code has previously made a call to System.disableUpdates();

Any advice how to fix this? What’s causing the problem?

** additional observations **

Using “lock and flash now” will initiate the problem for a running photon.
Removing the lock will NOT stop the problem for a running photon.
Removing the lock and then restarting the photon will NOT stop the problem.
Removing the device from the dashboard will NOT stop the problem.
Removing the device from the dashboard and then restarting the photon, WILL stop the problem.

“Lock and flash on reset” of a moded version of 5 (with just the version name bumped to 8) while the system is trying to lock and flash on update (5–>8), DOES NOT cause the problem. Presumably, no update, cuz both are listed as version 8.

“Lock and flash on reset” does not cause errors on 5 trying to upgrade to 8, until a reset happens. Then the error happens. Dashboard always persists display of (5–>8). Update never occurs. But error persists.

Programmatically re-enabling updates, does not result in the problem. That is, the following sequence, ends up with an update. So it seems the user blocking problem is only when its actively in disabled mode.
System.disableUpdates()

  • connect to wifi and particle
  • do some stuff
    System.enableUpdates();
  • eventually updates

ps. I’m using v0.4.7.

1 Like
2

i’ve responded to Dan personally on this issue. assuming the two of you are on the same team.

3

Hey @corey the issues we were talking about yesterday are different than this one. I don’t think this has been addressed yet.

1 Like
4

@mdma On a call with this team (CleverPet) right now and I’m just wanting to get a little more clarity on this issue above. Maybe 0.4.9 handles this alongside using system thread–which they were not using in this case above. To note, they’re using 0.4.7 as mentioned. Have you seen anything similar to this?

-Corey :sunglasses:

5

@mdma ping

6

Are you on the same team as the OP?
Otherwise just pinging people without any further comment seems a bit “rude”, especially people who haven’t been part of this discussion before.

7

hey @ScruffR I am, sorry about that! was logged into different account! I am on the CleverPet team

no rudeness or rushing intended esp not to @mdma who has plenty on his plate, just a ping to get a status update

:smile:

1 Like
8

The system gives the application 30 seconds to re-enable OTA updates by sending an update available event. This was built mainly with system threading in mind. I will add a change that doesn’t wait when single-threaded - the system will post the update available event and then continue immediately only if updates have been enabled. This will be released in 0.5.0.

2 Likes
9

PR is here - https://github.com/spark/firmware/pull/905

1 Like
10

Thank you! Will test.