LoPy4 - LoRa Nano Gateway - Guru Meditation Error
I'm running the latest LoRa nano gateway example here on LoPy4, firmware version: 1.18.2.r3, pybytes: 0.9.10. And a FiPy running OTAA node example.
Everything is running fine with TTN but for only few hours. I got data sent from the node and can receive data using an MQTT client connecting to TTN. After maximum 8 hours, the gateway always crash with either
Guru Meditation Error, core panic'ed (LoadProhibited)or
(Unhandled debug exception). I've tested it many times, always crash. The difference is in how long it will crash. Sometime after only approximately one hour.
Here is an example of error with
Unhandled debug exceptionis here.
Please could someone help me with this issue?
if you feel lucky, you might want to try our custom build just released on . More background about this is available through .
If we are lucky together, this will improve the stability significantly. If you will be still receiving the core dumps, I will be happy if you would share its content with us.
Please be aware that when upgrading to the current 1.20.1.r1 release these builds are based upon, you will have to erase your device completely before flashing in order to keep things straight. You will find respective references to this on the forum. Hint: Use
pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also .
Please also be aware that this procedure will also erase the LoRa MAC stored on the device. @robert-hh thankfully outlined the procedure to restore it appropriately:
- If you still know the value the LoraMac had before, then you can follow the procedure explained at https://forum.pycom.io/topic/1272/lora-mac-ffffffffffffffff/21.
- If you do not know it, you will have to use the Pycom updater to restore it:
- First, use the Pycom updater (GUI version) to install a recent image (like pybytes 1.20.1) from the Internet. You do not have to use it, the installation process itself already restores both the LoRa MAC and the Sigfox ID.
- Then, use the Pycom updater to flash the custom image. Do not erase the flash in between.
As it turned out to gain more robustness for others already [4,5], we will be happy to learn if this happens to you as well.
With kind regards,
P.S.: @titi: Especially, we would be interested if this firmware will be stable without the workaround you outlined above.
It appears that I've somehow "fixed" the issue.
Instead of pushing and pulling data to the socket in two timer-interrupt handlers, I've used flags to signal the udp thread, quickly ended the handlers. The flags are checked in the udp thread, where
gc.collectis called in the udp thread.
In addition to that, I've re-flashed the board with the
stablefirmware, so that it doesn't include
Everything appears to work fine so far. I'll let it run for a few days to check its performance.
@robert-hh Thanks for your info. Guess I'll have to wait for a fix and find another gateway for now.
robert-hh last edited by robert-hh
- The LoPy runs well 2-4 weeks in a row and sometimes stops. I did not look for the reason, but most likely it's power fluctuations. I enabled the internal Watchdog and to gc() in the main loop. For better robustness, I should add an external Watchdog. In general I have the impression that the LoPy is more robust than the LoPy4. Maybe there is still a rare race condition between SPI RAM and flash.
- The IC880A/RPi combo runs uninterrupted for a year now. Never stops, always serves messages well.
I should however mention that the traffic is extremely low. Besides the ones I create, I see about 1-2 message per day with proper CRC, and about 10 with bad CRC. The latter may be just noise.
@jason_gladen Did you find any way to fix the issue? I still get stuck with it.
I had a similar sounding problem with loramesh on LoPy1 firmware 1.20..(rc7 and rc8)