Our investigations around these random crashes diverted us into different directions. We have been able to confirm these on different Pycom devices, namely the FiPy, the GPy and the LoPy4.
There is the well-known LoadProhibited core panic fault occurring when uploading files either through the REPL using rshell or through FTP using lftp, see also
Guru Meditation Error: Core 1 panic'ed (Cache disabled but cached memory region accessed)
Guru Meditation Error: Core 1 panic'ed (IllegalInstruction). Exception was unhandled.
Memory dump at 0x4020fd14: bad00bad bad00bad bad00bad
However, things got even worse for some. This leads to the conclusion some errors have been masked by others and will only get triggered within certain edge cases.
From our research so far, we are still convinced that
In order to lighten up the conversation, I would like to divert it into a totally different direction here and would like to give you some readings about possible influences on silicon through ionizing particles, exposition to electromagnetic fields (EMF) and the topics of electromagnetic interference (EMI) [also called radio-frequency interference (RFI)] and electromagnetic compatibility (EMC).
Back to work. In the meanwhile, we became even more active on the Pycom user forum and by reading on the ESP-IDF in order to get additional insights into the problem.
Apparently, while earlier releases of the Pycom firmware has been reasonably stable, we want to recap that things obviously got more sensitive to random crashes with the advent of the Firmware Release v1.20.1 bringing in dual-core mode through upgrading to [IDF V3.2 and] MicroPython 1.11, which enables this by default [1].
We’ve built upon many of the aspects listed above and released another round of inofficial firmware images called 1.20.1.r1-0.6.0-vanilla-dragonfly based on Pycom’s 1.20.1.r1.