Flashing with SYSTEM_THREAD(ENABLED)

I have SYSTEM_THREAD(ENABLED) in my code.

When I try to flash it generally takes 3 attempts.

Attempt 1 - flashes purple and then freezes on purple. I wait a few mins and manually restart, the old code is still running.
Attempt 2 - flashes purple and then freezes with no light. I wait a few mins and manually restart, the old code is still running.
Attempt 3 - flashes purple and restarts. New code is running.

When I remove SYSTEM_THREAD(ENABLED) flashing works successfully.

At the moment this is an annoyance but once the Photons are deployed I will not be able to manually reset them so its really critical that the flashing works every time.

Has anyone else seen this behavior?
How can I fix it?
Do I just need to wait longer?

I’d suspect your code to be part of the trouble, but it’s hard to tell without seeing it.

I can’t post the code at the moment, I will try to strip it down and post if I cant solve this issue.

It seems strange that all works correctly when I don’t include SYSTEM_THREAD(ENABLED).

Are there any gotchas or things I need to be aware of when using SYSTEM_THREAD(ENABLED)?

@joe4465, where are you flashing from - IDE, DEV, CLI? I have no problems flashing RGBPongClock which runs 30us interrupts, keeping the photon quite busy. As @ScruffR pointed out, it might be related to your code so seeing it would help.

I flash my development devices from the DEV IDE and production via the organisations dashboard. I am seeing the same behavior with both methods.

I don’t have any blocking code in loop but I also don’t have any delays. Could this be causing it?

Yes, I think multi-threading is still a “beta” feature that is working well in lots of ways but might need tweak here or there.

You might have found something that needs a tweak.

1 Like

One of the main things you might need to take into account when using multithreading is that you will have shared resources which will be mutexed.
Possibly causing blocking sections where you might not expect them, that’s the reason where looking at the code might provide clues for someone who’s been bitten by it before :wink:

e.g Flashing with SYSTEM_THREAD(ENABLED)

1 Like

The main difference with having SYSTEM_THREAD(ENABLED) is that your code continues to run during the OTA update, while without threading your code is blocked.

A quick test is to comment out everything in setup/loop, just leaving the system thread declaration to enable multithreading. You can then slowly add parts of your code back in until the system fails.

Any other ideas of how to debug this?

It only happens ~one in five flashes so its quite hard to tell whether commenting out a specific part has helped.

I have set up my product to flash on reset. This means I upload the firmware to the product and then call a reset function on the Photon using my server. When flashing on reset does the user code still run?

Have you got to this yet?
It would help debugging :wink:

Ha yeah, I haven’t got time to do this at the moment. too much stuff still to add in before we release to our first customer on the 4th.

Hence why I was asking whether flashing on reset may solve the issue - if the user code does not run during the flash?

How about trapping your code in a tight “ready-to-flash” loop till things like System.enterSafeMode() or the underlying issue get solved?

Try calling this instead of resetting


void readyForOTA(uint32_t timeout)
{ // timeout == 0 waits forever
  uint32_t ms = millis();

  while (timeout == 0 || millis() - ms < timeout)
    Particle.process();
}

If you are not running any interrupts, timers or such that circumvet the intented behaviour of this, your other code should not be be able to interfere with the flashing.
And the fact, that the code keeps running for a while after flash, should not bother you, just be patient, till the device reboots by itself (max 25sec ;-))

yeah that could work, thanks.

I will give it a go and get back with the result.

Yep works.

Now to see whether the Particle Products Dashboard will reliably push any new releases within 30 mins of me setting the sensors to readyForOTA mode and releasing new firmware.

So I thought there was an option when releasing firmware via the Products dashboard to either: “Lock and flash now” or"Lock and flash on reset" but I can’t find it anymore (its there for manually selecting the firmware version but in my case i want to flash all my products devices once the firmware has been released)

Is it possible to release firmware and have it “Lock and flash now”?