Particle Flashing red? Why reboot?

I have a small fleet of Particle photons. I use them, love them, they’re an integral of my daily tech.

Now, why oh why for example, you have a bug in your code and the device goes into SOS mode, does the device reboot and run the same code again? What’s s the actual logic in this? If the code is broken, notify the user, and reboot into safe mode, don’t run it again!

The reason I ask is that essentially, you would need to ensure that there is always physical access to your device. What if it was installed in a ceiling for a sensor, or you installed an LED controller in a friends house, and they wanted something tweaked, you cant safely do that without the client potentially having to intervene without having someone [who may not be technically minded] to hold down one button, then when the light flashes…then…it all seems a bit peculiar that no one has asked for this before. Or does anyone know a snippet of code I can put in my scripts that may be able to do this?

Hi,

Welcome to our Forums! I’d love to know how you’re currently writing firmware and loading it on to your Particle device.

Additionally, could you share your normal process of developing in general? Could you also share your firmware perhaps?

Sadly I am not experienced enough to write my own firmware, nor would I know where to start, although I assume it would not be too hard to move to safe mode instead of reboot. If we look at the following diagram we can see:

  1. I don’t create block diagrams often
  2. If we look past that, the issue requires the presence of a person to physically intervene and break that loop. My thinking is, what if no one is present? You have a device stuck potentially that you may not be able to do anything about.

What I am asking is why doesn’t the photon run in the following way:

As developers, we deal with logic, and surely the second diagram makes for more logical sense than the first? What is the purpose of the particle rebooting, running code that doesn’t work.

1 Like

In your case, it makes sense to go with #2.

However, the other scenario that results in a SOS is an intermittent fault, such as memory corruption or a random bug in code. This might only occur after a long running time, and goes away, at least temporarily. Going into safe mode in that case will result in your firmware not running and would require someone to flash new firmware to it to get it out of safe mode. This would become unworkable for large fleets of devices.

However, if you really want that behavior during development, check the reset reason using System.resetReason() in setup(). If it’s RESET_REASON_PANIC, call System.enterSafeMode(). You probably want to also use SYSTEM_THREAD(ENABLED) so this happens immediately at startup.

2 Likes

rickkas You are my saviour! That’s just what I was looking for. Appreciate this snippet of code. Thanks for your help on this matter. This will save a lot of aggravation in the future for me.

You’re very kind!

One last thing, why is it so hard to get hold of photons these days? I hope they’re slowly not being discontinued?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.