FiPy crashes and does not reboot
-
I have a system with RS-232 based sensor, transmitting data every 10 minutes using NB-IoT. In between transmissions it goes into deepsleep. Now I'm facing a serious problem with my FiPy boards. The system runs for a few hours (sometimes up to 48 ) and then crashes. When monitoring it I occasionally saw a 'guru meditation error: core 1 panic'ed (loadprohibited).' message, but usually it does restart. But then, every once in while it does not. The LED is burning continuously bright blue, and the only way to recover is to switch power off and on.
Now I don't like the guru meditation errors, but I suppose I could live with it for now if the board at least rebooted. Does anybody know a workaround for this ?
(I'm running the latest firmware (1.20.2.r2), but I also tried with the previous version (1.18). )
-
Yea I think that is the best we have available at the moment. Now if you are using a Pysense or Pytrack, you could use the
pytrack.go_to_sleep()method to deepsleep or reset (power cycle) the module, but you will need to call that from the micropython of course.. There are some ways to enable watchdog timers internally but I have no expertise on that, nor do I know if the internal watchdog will detect a coredump..
-
@Gijs Found that as well. But it requires some kind of external watchdog circuit. Something I would like to avoid.
-
You can check out this forum thread: https://forum.pycom.io/topic/6418/reset-board-using-the-rst-pin-in-case-it-gets-stuck!
-
Thanks. I had not seen this 'Troubleshooting Coredumps' page before.
But somehow I think its not really a software thing. I've already minimized my program, removed WLAN access, disabled all timers etc. But it seems to happen when I switch the sensor on (or maybe if it starts measuring). As the page you refer to mentions these coredumps are often caused by bad power I assume I'll have to look for that. But still, it would be nice if it was simply impossible for the system to 'hang' completely.
-
Hi,
The Guru meditation coredumps are never a good sign.. Ideally we would not have any of those and we want to prevent them. While somewhat advanced, you can decode the coredumps and, perhaps, see where they are caused: https://docs.pycom.io/advance/coredump/. The Loadprohibited type could also be related to running out of memory, but let me know what you get!
Gijs