How (un)stable is ParticleOS 4.0.2?

We currently have a project running in test where a hardware watchdog reset occurs between every 4 days and ever day.

Is this to be expected from the (in)stability of ParticleOS or is this likely an issue with our firmware/hardware?

As Particle recommends using a hardware watchdog, I'm not sure what to expect in terms of long term stability...

Note to self: GME

There is no known instability in Device OS 4.0.2, certainly nothing that should cause a watchdog reset within days.

If you can see the status LED before the device resets that would be ideal. If the LED is off or a solid color, you're probably experiencing deadlock, which is most commonly caused by improper handing of threads, in particular the over-use of single threaded blocks or disabling of interrupts causing mutex deadlock between your code and the system.

The other thing to do is keep track of memory usage over time and make sure you're not leaking memory.

The hardest thing to debug is if you're corrupting memory, because you've overwritten the end of a memory block, overflowed the stack, or freed memory more than once. That will make the system unstable and either cause a SOS panic or it could cause your watchdog to fire.

2 Likes

Hey and welcome to the community!
I've seen projets on 4.0.2 that run for weeks if not months, so I would look into the code the device is running.

There is this Out of memory handler that you can use:

If you cannot look into the LED to find out the cause, since the issue may happen at random times, you could print the last reset cause with this code:

Be sure to also print (or publish!) resetReasonData so you get a better idea of where to start looking for issues.

Best

2 Likes

Please do not take this as a defensive comment, but more to give an idea:
Even cosmic rays can impact the behaviour of a perfectly functioning program. Just ask NASA!

The watchdog suggestion is something more generally recommended that only on Particle devices. If fact, all electronic devices that run code are recommended to include one to protect it from unforseen circumstances.

cheers

4 Likes

I seem to have solved the issue.

It turns out someone forgot to add the

System.enableFeature(FEATURE_RESET_INFO);

Before calling const int reason = System.resetReason();

which may have caused the semi-random resets. Which would make sense if
System.enableFeature(FEATURE_RESET_INFO); is responsible for allocating memory :wink:

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