I have an electron attached to an asset tracker that stopped reporting yesterday, but when I went out to the site it was still displaying the normal connection established led pattern. I’d assumed the fading was controlled by the platform software and would freeze if the electron completely locked up. Is the led fade controlled independently by hardware?
I’ve added the software watchdog, but I’d really like to have a hardware watchdog to insure recovery from a lockup like this. Does the CPU the electron is based on have hardware watchdogs available? I can build an external one if necessary but I’d rather use one on board if available.
The STM32F2 has hardware watchdogs, but currently they are not (easily) available for user code
But what system firmware are you using?
SYSTEM_MODE() is your code using?
Are you running
SYSTEM_THREAD(ENABLED) or not?
Is your code checking
The RGB LED is controlled in “software” not via dedicated hardware.
I didn’t set a SYSTEM_MODE() and do not use SYSTEM_THREAD. My code isn’t checking Particle.connected() or Cellular.ready().
The firmware version I will have to check, but it is the latest or very recent (last month).
Given that the LED is software controlled, I’m surprised that communication with the electron was completely lost.
Are you using Particle SIM or a 3rd party?
Since we don’t know your code we can’t say whether your code could be accounted for it or not but that’s usually our first guess and ofter applies.
I’m using the particle SIM, my code is taken from snippets for reading the GPS, PMIC, and a DHT22 attached to pin D2. I wonder how application code could crash in a way that leaves the platform updating the LED fade but not communicating with the cloud?
That would not necessarily be called crashing, but the code flow could be trapped in some “infinite” loop which somewhere calls
Particle.process() and hence keep the cloud connection going, but not execute the rest of your code - this might even be happening inside some poorly written library.
If you used
Particle.subscribe() you can actually check whether the connection actually still works while your code got “stuck”.
There is also a SIGNAL button in Web IDE to check responsiveness of the device or in console.partilcle.io/devices you have a PING button to do something similar.
But if Patricle.process was being called, wouldn’t the device respond to pings from the particle console?
Yes, it should. Did you mention anywhere that it didn’t?
I only understood the device stopped to report in
BTW, the not firing Application Watchdog also backs the assumption that
Particle.process() is called implicitly or explicitly.
Yeah sorry, no ping or particle.function calls responded. The application watchdog wasn’t in the code at the time of the crash, I added it afterward. Unfortunately I had removed the Serial.println statements originally in place so when I plugged in the USB cable I couldn’t tell if the application code loop was executing. I’ve since added them back in so if it happens again I’ll be able to see if the loop code is executing.
I also had several Particle.variable statements in place but could not read any of them either.
You may want to consider adding SYSTEM_THREAD(ENABLED), as well as, testing for connectivity prior to doing cloud functions like Particle.publish(). Having the user app on its own thread allows smoother operation IMO, especially with Software Timers.
Do note that the Software Watchdog is not a panacea as the system firmware will kick it over in the background so even if the user app freezes, the Watchdog may never timeout. This is being addressed for a future release.
I’ve seen some example code that uses SYSTEM_THREAD(ENABLED) and checks connectivity so I will try that. If the software watchdog simply insures the platform keeps responding that will be enough for now, I have a Particle.function that calls System.reset if I have to manually reboot but it wasn’t responding last night (I hadn’t put the watchdog in the build at that time).